I am spending most of my time as of late providing management consulting services to my clients.  Most of them have made, or are making, the transition to Agile and often facing the same set of issues.  While I think there is no replacement for a good Management Consultant/Agile Coach, a close second is reading as much as you can from those who have successfully made the transition to Agile.  With that, I would like to present a select list of my favorites:

         

I was recently asked: “What mentoring techniques have you used to help engineers make the move into management?”  Great question!

While there are many tools that can be used here, I think it’s important to start with some key factors in making this jump:

1. Engineers thrive on building things and the resulting sense of accomplishment when it’s built.
2. To improve yourself, the must be an awareness of the improvement area.

 

Starting with the first point, I’ve seen (and personally experienced) a sense of floundering when engineers are asked to manage others.  Being used to writing code all day they often feel like they aren’t accomplishing anything day after day.  As far as I can tell, there is no way around this and represents the first half of the chasm.  Tool #1, Patience.  We must remind our manager in training that what they are experiencing is perfectly normal and that things take time.  Additionally remind them that the sense of accomplishment will return if they are willing to be patient. In John Baldoni’s book, Lead by Example, an entire lesson (#7) is devoted to this topic alone.  Tool #2, Communicate…then communicate some more.  In the realm of engineering it is common practice to communicate things only once and expect that they are understood, in reality this is rarely the case.  Give people direction, set clear expectations, talk about team goals, discuss the vision of the company…rinse and repeat.  Your team must understand what you expect from them and start including these expectations in their decision making process, this takes time and repetition.  Tool #3, Watch for changes.  As our management in training begins to use the first two tools, have them watch for changes in behavior on the team, however subtle, that may be a result of their leadership.  This tool is the preface to regaining that sense of accomplishment.  As the team begins to respond to our manager in training’s leadership there will be changes to team dynamics.  These changes may be positive or negative depending on the many factors, but awareness of the change is important.  The ability to detect changes in the team based on decisions made by our manager in training represents the second half of the chasm.

On the second point, we need instill in our manager in training (and remind ourselves) that having an awareness of an improvement area is the first step in making changes.  For out manager in training to use the tools above, they must be able to see how certain aspects of their experience, education, personality and management style impacts what they do.  It is the job of the mentor to make them aware of this. (albeit tactfully)  If there is no awareness it is unlikely to be improved upon.

This is far from a complete list but instead represents some of the basics. I hope that it’s helpful and, as always, I welcome your comments.

The more software development teams I work with, the more I’m convinced that it’s often nearly impossible for said teams to see where there are issues.  From the managers of these teams I hear:  “If people would just follow the process we would be in great shape!” or “We really don’t have many issues.”   From the team members I hear “We’ve tried following our process and it just creates more work for us!”  or “Management doesn’t get it!”  If these statements sound familiar to you, you’re not alone. 

Improving your organization’s ability to deliver software in a streamlined way can be a daunting task.  I liken it to having issues with your golf swing.  You can make corrections that you hope will have a positive effect, but often they morph one problem into another.  In most cases it is better to have someone else examine your swing.  A coach or consultant looking in from the outside typically has a much clearer view of what is going wrong.  If this consultant has the experience and a keen eye, he can make suggestions that will have a greater impact in a shorter amount of time than you could on your own.

The point here is that if you are looking to improve a management area in your organization, give a reputable consultant a try.  They just might see the real issues and allow you to be under par on every hole! :)

I have founded or co-founded a number of startups, worked as a consultant for Fortune 100 companies, and been an executive in large corporations.  What I’ve come to hold true is that as a company grows it experiences what Dr. Larry E. Greiner calls “growth phases.”  Dr. Greiner postulated the existence of these phases in a 1972 paper titled “Evolutions and Revolutions as Organizations Grow.” These growth phases are characterized by certain periods of growth ending in a crisis.  The duration of the crisis period can lead to what I call “growth plateaus” resulting in stalled or declining revenues.  The phases and associated crisis are as follows:

Greiner Phase/Crisis	Behavior
P1. Creativity	Creative “start-up” atmosphere.  Everyone can where any hat.  Very agile and reactive to client demands. Co-founders motivated by partial ownership.
C1. Leadership Crisis	Managers need to begin specializing.  New employees not motivated by ownership.  Need for process and controls resisted.  Co-founders still want to do everything.
P2. Direction	Functional organization structure is established.  New employee incentives introduced.  More formalized communications. First step of separating strategic and functional specialists.
C2. Autonomy Crisis	Organizational structure inappropriate.  Lower level employees feel “disconnected” from senior management.  mid-level managers start taking initiative on their own instead of following the process. Senior managers feel that they are losing power.
P3. Delegation	Concept of more autonomous business units.  Senior leadership more vision based.  Profit centers, bonuses and incentive programs used to stimulate motivation.
C3. Control Crisis	Senior management seeks to regain control of autonomous business units.  Possible attempts to centralize control.
P4. Coordination	Autonomous business units merged into groups. ROI becomes an important metric in measuring a units success. Redundant cost centers centralized. (IT, accounting, etc.)
C4. Red Tape Crisis	Programs and process begin to limit business unit’s ability to generate revenue. Innovation is dampened. Organization is now to large for formal programs and rigid systems.
P5. Collaboration	More flexibility in management.  Skilled managers effective at intrapersonal management.  Teams exhibit more self-discipline.  Focus on problem solving.  Rewards are team based instead of individual based.
C5. Internal Growth Crisis	Problem solvers exhausted from intensity of the work.  Effectiveness becomes unsustainable and cyclic.
P6. Extra-Organizational	Use of mergers, holding companies, networks of companies to sustain growth.

 

From the above, can you fit the company you are working for into any of the phases?  Are you in a crisis?  The funny thing is that employees usually seem to know if they are in a growth phase or experiencing a crisis.  Depending on the quality of the management team the crisis may be temporary or may last for years.  If you are stuck in a crisis for years, you will usually see a high volume of management turnover and hear phrases like “This has worked for us before.  It will work for us now!”  Then the revenue begins to slide. If senior management sticks to their guns, this is the beginning of the end.

What does the flipside look like?  Good leaders embrace the ability to change processes and practices if they are no longer working. (Agile Management)  Some, feeling they are only an effective as a Phase 2 manager, may choose to remove themselves from the organization completely.  According to Dr. Greiner, organizations should not attempt to bypass phases or their associated crises. Instead he recommends a few tools to managers to help them move to the next step.

 

1. Know where you are in the development sequence.
2. Recognize the limited range of solutions.
3. Realize that solutions breed new problems.

 

Here are a few good books that discuss Dr. Greiner’s concepts as well as strategies to deal with each crisis.

 

Managing Technology and Innovation: An Introduction

 

Dynamic Strategy-Making: A Real-Time Approach for the 21st Century Leader

 

Evolution and Revolution as Organizations Grow

I received a couple comments on my post about Prioritizing SaaS Features.  One comment was focused on the use of EV and AC which I will address later, the other was on the use of Ideal Hours.  The comment on Ideal Hours was from Rob Park, an Agile Coach from Colorado.  Here is an excerpt from Rob’s comment:

The one thing I feel is optimistic about your calculation is the ideal hours though. Ideal hours are not actual hours, so I think you need another factor in there to convert to actual hours based on actual velocity trends.

Great point Rob!  While Ideal Hours are not representative of Man Hours, there are a few tools I use to try to get them as close as possible i.e. the conversion factor as close to 1 as possible.  First, team members sign up for tasks and estimate as part of the iteration planning and decomposition process as discussed here.  Second, estimates for specific team members are tracked against actual time as discussed here.  This gives us our margin of error for a specific team member that we can use to size our buffers.  Third, we use the process described here to evenly load the work onto the team for the iteration. Finally, if tasks change hands during the iteration, estimates and cost curves are adjusted accordingly.  This may cause an item(s) to get descoped during the iteration and technical debt to increase, but this hopefully will be addressed as part of the next iteration.

So why not just use Man Hours?  I like the concept of Ideal Hours because it gives you more flexibility on estimates.  The term Man Hours has rigid foundations in project management that do not work well in the Agile world.  Think of it this way.  With Ideal Hours we try to approach real Man Hours and use a factor to determine how right (close) we are.  With Man Hours we consider estimate accuracy a measure of how wrong we were.  Ideal Hours just fit better into Agile thinking.

I had a discussion with a colleague yesterday on how to determine the priority of features on a given service. We quickly arrived at the topic of assessing business need, i.e. value, of the features. This is a conversation I've had many times, with many clients and thought it might be worthwhile to document some of my thoughts on this.

If you are building "shrink-wrap" software you can estimate the number of units sold and multiply by the price to get annual revenue. From there you can work backwards to establish your financial metrics. (ROI, NPV, IRR, PV, EV, AC,T,I,OE, etc.) But what about when you are building Software as a Service? This is not a simple question to answer. Regardless of the level of difficulty, it is one that many of us will need to answer in order to effectively grow our organizations. While I don't have a one size fits all answer here, I would like to toss out some tools, ideas and links that may help each of us answer the question for ourselves.

Know Your Value

For starters we should have a good understanding of the value proposition(VP) for the service. The VP will speak to why clients will choose your service over the competition. The VP will look something like:

"For sales teams seeking to reduce time-on-sale by as much as 25% our CRM application will provide full sales process management at half the price of the competition"

Or

"Our internal CRM application will allow our sales team to reduce time- on-sale by 25% and cost only 50% of an off-the-shelf package".

Here is some additional reading:

Developing a Compelling Value Proposition

Stop Coding, Start Marketing! Getting Your Positioning Right

Powerful Value Propositions

Bringing the Value Back Into Value Propositions

In Search of a Value Proposition

Understand the Features That Support Your Value

We add features to attract new clients, keep existing ones, or generate new sources of revenue. We should be doing this in alignment with our VP. We should not be adding features simply because we've conceived of the idea. Given that, we should start by asking ourselves "How important is this feature relative to our VP?" Let's start by using the following 5-point scale for each feature:

1. Direct VP feature.
2. Component part of a VP feature.
3. Compliments a VP feature.
4. Nice to have.
5. Optional.

When analyzing the features that support your VP, remember that only 6% of the work on software projects is value added and 64% of all software features are rarely used. (Thanks for the numbers Ryan!)

Price your Value

After you have the VP and the features to support it, you will need to work with your sales and marketing organization to understand what they feel the market will bear, in terms of price, for each unique service. They should also have an estimate on the number of users that will subscribe to the service. Jason Rothbart talks more about this here. Combine this with an innovative monetization model and you have some annual revenue numbers you can work with.

You may also be in a project that has the role of supporting the business. If this is the case, an estimate of the value to the business should still be generated. You may choose to adopt the model that if the service saves the organization 1 hour during a 40 hour week then 2.5% of the annual revenue is attributable to the project. For a $40M company this is $1M annually!!!

If there are no answers to these questions, you may be in the "build it and they will come" mode which is very difficult to generate value metrics from. Try using one of the above models to create an estimate and see how it compares to reality when everything is said and done.

Finally, you should consider what monetization models will be used by your service. Will you only generate revenue from paid subscriptions or will you adopt a freemium model? Will there be paid advertising from within the UI of your service? Are there client stakeholders that are willing to help fund the service? All these are examples of monetization models that will have an impact on revenue and need to be considered as part of the analysis.

Market Lifetime

Given the speed of today's market, including the market lifetime in your analysis is also important. Every service has a limited lifetime due to advances in technology and usefulness to the client base. Typically the market lifetime curves are bell shaped (Figure 1) since full market adoption is not gained immediately and decays slowly due to technology and market pressures.

Figure 1 - Typical Revenue Cycle

How long will your service be able to generate revenue in its current state? 6 months, 1 year, 2 years? If you assume the lifetime to be 2 years and the revenue curve to be bell shaped with the max subscribers in the middle, you can make some fairly good estimates. The answer to this question will play an important part to developing the Value Schedule.

Bringing It All Together

Let's assume that we've determined we will generate $1M over the next 2 years on our service. In order to generate this revenue, we will need to add continuous value and bear continuous cost over the next 20 months. Let's further assume that we will be on 2 month release cycles over these 20 months giving us a total of 10 releases.

Using our 10 releases and our $1M in revenue we can simply calculate the value per release to be $100K. (Ignoring any discounting)

Now if we look at the first release and assume that we have 25 features all of which we have ranked using our 5-point scale from above we can estimate the dollar value per feature. The trick is to normalize the value based on the rank. The formula is shown in Equation 1.

Equation 1 - Feature Value Equation

Using Equation 1 in our example we can now generate a Value Schedule which will give us the dollar value of each feature.

Feature	Rank	Value
1	1	$ 4,902
2	1	$ 4,902
3	1	$ 4,902
4	1	$ 4,902
5	1	$ 4,902
6	1	$ 4,902
7	1	$ 4,902
8	1	$ 4,902
9	1	$ 4,902
10	1	$ 4,902
11	1	$ 4,902
12	1	$ 4,902
13	2	$ 3,922
14	2	$ 3,922
15	2	$ 3,922
16	2	$ 3,922
17	2	$ 3,922
18	3	$ 2,941
19	3	$ 2,941
20	3	$ 2,941
21	3	$ 2,941
22	3	$ 2,941
23	3	$ 2,941
24	4	$ 1,961
25	4	$ 1,961
		$ 100,000

Conclusion

While not the answer for everyone and realizing I've left out some detail, I hope the tools I've presented here will be useful to you while you are analyzing your next project. I would love to hear what you think!

Is it just me or does anyone else think it's a bit funny I'm having trouble finishing David Allen's Getting Things Done? I've heard a lot of people say they love it, but the first few chapters just talk about what's going to happen later in the book. Does it get better?

Reading Tom's Interruptions and the Knowledge Worker post got me thinking about recent interactions with a large consulting firm I talked to. During the first phone conversation with a senior recruiter, she interrupted me to take a phone call on her cell phone. After further discussions I chalked it up as a fluke and agreed to meet with her. During our meeting we were interrupted by another member of her staff informing her of the "important call" she had been waiting for. She promptly excused herself not to return for 45 MINUTES!!! She apologized profusely, but clearly this was an ongoing problem with this person. If I was not enough of a priority to dedicate one hour of SCHEDULED time, then what was it going to be like if I worked for them. Needless to say I am not in discussions with them anymore. Is any call really that important? (baring family emergencies) Do people think it makes them "look" important? As Tom says:

I figure that the cost in time (read money) to the company of an interruption to a fellow employee and me discussing business gets expensive when you consider the down time of the two of us, while one of us takes a cell phone call (or answers an email, etc.).

Eric Wise posted a great article about Keeping Talent. You'd think after more than 20 years of doing this, companies would have figured it out. Apparently not. Now, who wants subs?

I've managed my share of software development projects. While I always try to take a proactive approach to deadlines and decisions, sometimes you are at the mercy of the project sponsor. After reading Seth Godin's article, Hurry!, I had to laugh. How many of us have been, or worked for people, in this mode? I have a title for myself when I'm working for clients that work like this..."Fireman." We've all seen it "Oh no! A client found a bug in our beta release! Drop everything and fix it!" or "Marketing decided that our app that will launch in 2 months need to have a purple color scheme! Drop everything and make it happen!" Managers that are in this mode often fail to think about the impact of these "urgent" decisions. They are only looking at WHAT is being asked of them without any thought to WHY. I (like Seth) feel that if these people don't ask WHY it's because they don't want the responsibility of dealing with the ramifications. For example, if we don't make the app purple, then marketing can say that the reason it didn't sell was it wasn't purple. It's a prime example of CYA behavior. They feel that if they do exactly what is being asked of them, they take no responsibility for failure. How many successful people do you know blindly follow directions without question? Food for thought.