If You Were Starting a Software Company With Your Own Money, Would You... ?

If you were bootstrapping a software company with your own hard-earned cash, what software development practices do you believe in enough that you would use them right off the bat?

You have to vote to see the results. There is a link below each poll which links to the next. There are 15 in all. The first is on your role, the rest are about which dev practices you value.

[Note to the jaded cynics: the polls really do only collect votes, your privacy is assured]


Next: Poll: Continuous Integration Benefits

Agile Transformation Seminar

If you are in the Boston area, consider going to the Agile Transformation Seminar on Thursday February 26th in Lexington. The seminar is a 1/2 day in-depth look at the business benefits of Agile and includes a case study on Avid's Agile transformation. My session will be about the effects of Agile on the needs of your tool infrastructure.

What I Believe About Agile

Before I get too far into what I believe about Agile, let me give a little background. In 2005, I was a staunch Waterfallian. Stuff happened (blogged elsewhere) and then I turned into an Agile advocate.

There are two important things that I believe about Agile. First, while I do believe that being Agile is more than just a set of practices, I also believe that there are a set of practices which are so good that for me they define what I currently think of as Agile and believe everybody can do them and would benefit from them.

Here are the practices which currently define “being Agile” for me. These are roughly in order of benefit: short iterations (preferably 1-2 weeks), Kanban (as an alternative to short iterations), backlog, one piece flow, continuous integration, whole teams, collocated whole teams, test first/test early, use of a product owner, incremental design, refactoring, unit tests, multi-stage continuous integration, user stories, sustainable pace, task assignment and estimation by team members, stand-up meetings, burn-down and burn-up charts, iteration review, retrospective, and frequent releases. There are other good practices out there, but these are the ones that I believe will become mainstream.

Second, and most importantly:

I truly believe the benefits of Agile are significant enough to focus your resources to get to the point of saying this sentence.

This is based on the belief that the algorithm of Agile is just plain better than traditional development combined with direct observation of the significant benefits experienced by both external and internal teams.

To put it another way, if you are not yet investing in Agile, I believe it is the #1 investment you can make to increase your productivity, quality, revenues, customer satisfaction, profitability, and employee satisfaction. It is possible to invest in Agile but not get these benefits. If that is happening to you, I urge you to stick to your guns and look for help. Getting to Agile is worth the investment. It is worth redirecting resources, changing priorities, and doing what it takes to get there.

The web book “Zero to Hyper Agile in 90 Days or Less” is a good place to start.

You may also be interested in “The Top Ten Reasons I May be Wrong That Agile is Better” .

The Top Ten Reasons I May be Wrong That Agile is Better

First of all, it is important to note that "Agile" is just a word and means different things to different people. There is a good chance that we have different definitions of what “Agile” means. If you want to know what I mean by Agile, please read “How Agile Works in a Nutshell”.

10. “Customers don’t want frequent releases.”

That’s often true, but it is not actually an impediment. While frequent releases are an important benefit, it takes time to get to that point, isn’t the right option for all situations, is just one of the benefits, and is not required to get the other benefits. Read more in a series of posts on this subject.

9. “The advocates are overzealous and arrogant.”

Yes, some of them are. But not all of them. Many people are overzealous and arrogant, that’s not unique to Agile. It is the concepts of Agile that make Agile worthwhile, not the advocates.

8. “It is all just a marketing ploy. You don’t really believe Agile is any better than traditional development and in fact it is just more of the same stuff in a shiny new package. You just want to hop on the buzzwagon.”

This one is hard to refute. The only way I can dispel that belief is if you get to know me better.

7. “I haven’t tried it, and I believe Agile Development is a good development method, but it is just another flavor. Whatever works for you.”

You may be of the opinion that traditional vs Agile is just a preference/philosophy/ideology thing, like chocolate vs strawberry, Aristotle vs Plato, Democrat vs Republican. But then in that case, why would anybody go to all of the effort of investing in Agile? Tech folks don't generally make massive switch-overs from one way of doing things to another just for preference or just to be 2% more productive, they generally only switch in order to get an order of magnitude improvement. So, if it is just a preference thing, there's not much to talk about (from my perspective).

6. “Yeah, I tried that Agile thing. What a disaster!”

There are any number of reasons for failure. I've seen plenty of cases of Agile failure. But in every case that I've seen "Agile failure" it was either because it wasn't really Agile that was being done, or there was a major impediment. An example of a major impediment would be that the attempt was initiated by executive decree followed by no investment in success and a goal of 100% Agile within an impossibly short amount of time. I realize that saying “it probably wasn’t really Agile” sounds pretty convenient. But, I have yet to hear anybody say "I feel like we were really doing it right, but it just didn't work." If that's something that you would say, I'd love to hear from you.

5. “Yeah, I know a group doing Agile and they are really successful. But they would succeed anyway because they’ve got all of the best people on that team.”

All I can say to that is that for me Agile is only worthwhile if it is something that has mainstream applicability. If it won’t work for the majority of teams, it isn’t interesting to me.

4. “I believe that you believe that it is better, but I can clearly see that it is not. I don’t know what your reasoning is, but it is clearly wrong.”

This is exactly what I was saying in 2005. Well, that works both ways and I’ve been on both sides of it. All I can say is that I believe it is worth your time to consider that if so many people that have devoted so much energy to the software development process believe that Agile is a good thing, then maybe there really is something worthwhile about Agile and it is worth your time to learn more about it.

3. “You don’t really understand how successful traditional development can be, and there are probably a bunch of techniques for success you are not aware of.”

My career for the past twenty years has been to contribute to the software process improvement efforts of countless companies. So it isn’t that. By the way, if you haven’t heard of the Niagra method (the best traditional development method), you should take a look.

2. “You have blind faith in Agile. You want it to be better and you will ignore any evidence to the contrary.”

Well, you'll have to take my word for it that I'm a very pragmatic person. If something isn't working, and it doesn't look like it is going to, I don't have a lot of patience to continue doing it just because I think it should work. I originally believed in Agile when I realized that it is algorithmically better than traditional development. But now I believe in Agile because I've experienced significant benefits from practicing it.

1. And the number one reason I may be wrong is the one I don't know about yet. If you've got a good one that I haven't covered, please let me know. I look forward to your thoughts and feedback.

Next: What I Believe About Agile

Agile Twittering

In case you haven't already been bitten by the twitter virus (what else to call it?) the whole Agile world seems to be on twitter. Now, I'm there too! What's next? The hive mind? :-)

Getting Management and Engineers Out of Each Other's Hair

This is the fifth in a series of posts on self-management that began with "The Use of Self-Managing Teams Outside the Context of Software Development."

Short Iterations Increase Management Leverage
One of the hardest jobs of a manager is discovering and resolving problems. If you don’t know about a problem, you can’t resolve it. If you discover a problem late, you can’t do much about the negative effects it has already had. If you don’t get feedback on the results of the actions you take for a long time, it is difficult if not impossible to judge the effectiveness of your actions. Short iterations, the practice of breaking up a release into 1-4 week development cycles that each produce a shippable increment of work, vastly increase the amount of feedback available to management for making good decisions. It also provides more opportunities to make adjustments and judge their effectiveness.

Burndown Charts are a Management Dashboard That Everybody Loves
A burndown chart is a useful tool for measuring the amount of progress, positive or negative, during an iteration which clearly illustrates trends which may indicate problems. It is simply a day-by-day chart of how much effort remains. At the beginning of an iteration, 100% of the work for that iteration remains. At the end of the iteration, there should be 0% remaining.

An important multiplier of the effectiveness of a burndown chart is its visibility. A clearly visible burndown chart makes it obvious to everybody how the project is progressing. Nobody wants to see a burndown chart that isn’t making progress, and nobody wants other people to see lack of progress for a significant period of time. The burndown chart helps to motivate and inspire. If your own work is going well, but the chart isn’t going down in general, you’ll be more engaged in helping to solve problems that the team is having overall. When used effectively, the burndown chart reduces the effort required for a manager to determine that there is a problem and also reduces the need for the manager to cajole the team into taking corrective action.

Retrospectives Emphasize That You Are All In This Together
A retrospective provides a forum for the team to talk on a regular basis about what worked and what didn’t work as a team, to discuss ideas for improvement and to work out problems. Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action.

User Stories Reduce Micro-Management
Agile prefers user stories over requirements. User stories are simply stories that describe what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome. The separation removes the invisible constraints which can appear when the engineer assigned to a task is given a specification which completely constrains the problem such that only one solution is available. By focusing on the outcome desired by the user, the engineer working on the task has more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

There are two reasons that user stories support self-managing teams. First, they reduce the temptation of technically minded managers from becoming an implementation bottleneck. Second, they encourage team members to innovate and take on more responsibility which increases their self-sufficiency. This is much easier to do within an Agile environment because there are more practices in place such as short iterations, burndown charts, and retrospectives which encourage learning while reducing the risk of making mistakes.

I hope you have enjoyed this series on how Agile practices reduce and redistribute the job of management and thereby increase your capacity for self-management. If you missed the beginning, the first posting is "The Use of Self-Management Outside the Context of Software Development" .

You may also enjoy reading the the online mini-version of the book that I am working on called "Zero to Agile in 90 Days or Less."

Three Cures for the Management Bottleneck

This is the fourth post in a series on self-management that began with "The Use of Self-Managing Teams Outside the Context of Software Development"

Divide and Conquer
One of the ways that Agile, especially when using Scrum, reduces the management bottleneck and enables self-managing teams is by having clearly identified roles and responsibilities. Two very useful roles are those of Scrum Master and Product Owner. The Scrum Master role clearly frames the project management function. The Product Owner role clearly frames business management related to the product that a team produces. Both of these roles clearly delineate an area of responsibility that would normally be done by a traditional manager and makes it possible to delegate those responsibilities.

The Scrum Master
In Scrum, the Scrum Master is the person making sure that the (Scrum) process is working, looking for and removing impediments, and acting as a liaison between management and the team. Regardless of what you call the role of Scrum Master, the role itself does not require you to be doing Scrum.

The Product Owner
The role of Product Owner also comes from Scrum. As with a Scrum Master, the use of Scrum is not required in order to have a Product Owner. However, the effectiveness of the Product Owner is definitely leveraged by Scrum. The Product Owner is the person who is solely responsible for the content of a release. They are responsible for all decisions related to what changes are made to the product, including all defects and enhancements. Of course, the Product Owner is most effective if they gather information from a wide variety of sources and work closely with all stakeholders. A Product Owner that regularly makes decisions without consulting with stakeholders or acts on a whim won’t be a Product Owner for long.

The Product Owner Needs a Product Backlog
The role of Product Owner goes hand in hand with the use of a product backlog. A product backlog is simply a list of high-level product requirements (preferably in the form of user stories), prioritized by business value as determined by the product owner.

A backlog gives a clear context to discussions of priority. Anybody can go and look at the backlog to see the position of something they have a stake in. If it is lower than they think it should be, they can examine the backlog to see what is higher in order to help frame a discussion around either moving it higher or moving other things lower. Thus, many people can be leveraged to collectively groom the backlog. This distributes the work of grooming the backlog and helps to ensure that the team is focused on the highest value to the organization.

Reducing the Management Bottleneck
Even if the roles of manager, Scrum Master, and Product Owner were all handled by a single person, the use of these roles and their artifacts simplifies the job of management while at the same time amplifying its effectiveness. And of course, that makes it even easier to delegate these roles. The more that management is delegated, the less chance that management will become a bottleneck.

Next: Getting Management and Engineers Out of Each Other's Hair

No-Brainer Self-Management Practices in Agile Part 2

This is a continuation of "No-Brainer Self-Management Practices in Agile Part 1"

Whole Teams Improve Coordination and Communication

A whole team is a small group of people (no more than 12) that work together towards a common purpose, primarily spend their time as part of the team, and as a team have all of the skills they need in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, scrum master, product owner, etc. The whole team practice contributes to self-management by reducing the amount of coordination required in order to achieve a goal. For instance, instead of having to coordinate with a QA group in order to find somebody that can test a piece of software, having a QA person as part of the team means that there is always somebody familiar with the software available to test it.

Another benefit of having a whole team is that it makes it more obvious if you have resource imbalances. If the QA folks in the team can’t keep up with the developers, then you either have too many developers on the team or too few QA folks. If your front end developers can’t keep up with the folks working on the back end, then you have a resource imbalance. You either need to add more folks with the right skill set, or you need to reduce the amount of work being done on the back end.

When you have a whole team, you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects. Taken together, the benefits of whole teams can have a significant impact on reducing management complexity which makes it easy for teams to do more self-management.

Collocation Further Improves Coordination and Communication
Collocation is closely related to whole teams. Collocation is simply having everybody in close proximity to each other. This compounds the coordination benefit of whole teams.

If you have a large group of people that are not all near each other but they are all working towards a single deliverable, collocation may seem impractical on the surface. However, collocation at the whole team level is more important than collocation of multiple teams. Focus on creating whole teams that can collocate rather than collocating the whole group of people.

The challenge with both whole teams and collocation is that they often require either relocating people, changes to management structures, or both. However, the benefits of having a tightly coordinated team working towards a common goal far outweighs the difficulties associated with creating collocated whole teams.

Next: Three Cures for the Management Bottleneck

“No-Brainer” Self-Management Practices in Agile

While there may be some confusion over the meaning of self-management in Agile, not to mention some contention as to whether or not it is a good idea, many of the Agile practices contribute to self-management without requiring the wholesale adoption of self-management. For simplicity, I will define “self-management” as anything that is done by a team member that would traditionally be done by a manager. The practices contribute to self-management either by reducing the amount of management required or by encouraging the delegation of management tasks to team members. Some practices do both. As a result, managers have more bandwidth for dealing with things which are a more leveraged use of their time.

The Agile practices related to self-management include:

• whole teams
  
• collocation
  
• short iterations
  
• using a scrum master
  
• using a product owner
  
• user stories
  
• maintaining a product backlog
  
• assignment of tasks by team members
  
• estimation of tasks by team members
  
• producing a burn down chart
  
• retrospectives
  

Simplifying and Redistributing the Management Load
Let’s start with a simple example: task assignment. Traditionally, tasks are assigned to engineers by their manager. In Agile, tasks are selected by the engineers themselves. It may take some time for everybody to get used to this and to work out the kinks, but the practice itself is not particularly earth-shattering.

Certainly, somebody may find themselves struggling with a task they don’t fully understand, or one engineer may accomplish a task more slowly than whoever the manager might have chosen to do the task. But is that really all that different than what typically happens when the work is assigned by a manager? How likely is it that a manager has enough time to devote to the minutia required to optimize task assignment? Wouldn’t it be better for the manager to spend their time mentoring team members on how to pick tasks that are appropriate for them while at the same time encouraging engineers to stretch their capabilities?

Next: "No-Brainer Self-Management Practices in Agile Part 2"

The Use of Self-Managing Teams Outside the Context of Software Development

[Note: this post was heavily edited on Jan 18th to take into account comments on the earlier version.]

Most of what you need to do to become Agile requires only re-arrangement of what you are already doing. For instance, managing a backlog is still a process of deciding which work to do and in which order to do it, it isn't something that boggles the mind and makes people say "some people might be able to do that, but I don't see how we could." Managing what work to do with a backlog is like tuning an engine. It is straight-forward to explain, learn, and implement. Whereas, moving from conventional management to self-managing teams sounds like moving from steam to internal combustion. It is completely different and not well understood. But wait, what exactly are self-managing teams?

The terms “self-organizing,” “self-managing,” and “self-directing” have been used to mean many things, but are generally thought of as being in the same ballpark. In this post I will use the term “self-managing.” While looking for other writing on the topic prior to writing this post, I found that it is a poorly defined topic within the Agile literature.

What the Heck is a Self-Managing Team Anyway?
What sort of management does self-management apply to? What is the scope? Does it just apply to how I manage myself on my pre-assigned tasks? Does it only apply to project management? Does it mean dealing with hiring and firing? What about budgets? Some folks have taken it to mean that there is no manager, that the Scrum Master is the manager, etc. Sure, there are lots of short sections on self-managing teams in Agile books and articles, but it is not much more than a vague description of the concept repeated in different ways by different authors. This is not a criticism, only an observation that self-management it is an underdeveloped area of Agile.

In the Poppendieck's "Implementing Lean Software Development" there are four pages on "Self-Directing Work", most of which talks about project management. Kent Beck's "Extreme Programming Explained" takes self-management for granted without specifically talking about it. Ken Schwaber's book "Agile Software Development With Scrum" contains a couple of paragraphs on self-organization but mostly takes it for granted. In general, most of the material on the topic assumes that you will be doing it and there are practices which are meant to support it, but there is no in-depth discussion of exactly what it is and how to do it.

In searching the web for a more in-depth treatment, I did find one really good article by Esther Derby in the December 2008 issue of Better Software Magazine entitled "What's a Manager to Do?" This article gives a good overview of the concepts as well as some pitfalls and how to avoid them.

I had better luck finding reference material on self-management by looking outside of software development all together. At some point during my searching, I accidentally left off the keyword "Agile" and discovered that there are whole books on self-managing teams, and they have nothing to do with software development at all. I ordered three of them and am currently in the process of reading them. I'll post new entries as I go.

Here are the books on my reading list related to self-managing teams:

Business Without Bosses
Leading Self-Directed Work Teams
The Wisdom of Teams

Apparently, people have been promoting and practicing self-managing teams completely outside the realm of software development for quite a while. While it holds promise, it does not yet seem to have become a widespread practice. If it is still in its infancy in general, is it really a good idea to promote it in conjunction with all of the other parts of Agile which, IMHO, are much more straight-forward and are closer to our core-competencies as an industry?

Even though self-managing teams are not well defined or described in Agile, it doesn’t really matter. There are actually many no-brainer “self-management” oriented Agile practices that are straight-forward and beneficial in their own right. The fact that they may get us closer to creating self-managing teams is a side benefit.

Next: "No Brainer Self-Management Practices in Agile"