At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is often one of the first things to be dropped from a team’s implementation of Agile methodologies: the Retrospective. It is a shame, too, because the team that does this will, over time, operate more smoothly and with ever increasing velocity and job satisfaction.

The retrospective is more than just a ‘bitch session.’ Recognizing what went well is a key element in getting people to open up and participate.

The ‘negatives’ should also be constructive. Divide them up into categories: What is within the team’s power to control? What is outside of their control but can be influenced by them? What items are they completely powerless to change? Then for those where there is control or influence, identify the change that will help make the problem better. Resolve as a team to implement those changes.

But there is more. This time can be used to do anything that will make the team more effective. Learn new technologies. Meet with the business users. Get some Agile training!

Bottom line: Do it. Don’t skip it.

The best architectures, requirements, and designs emerge from self-organizing teams.

One person, even a person with many years of experience, a giant in their field, a brilliant individual, can not be as productive as that same person would be if they were working together in a cooperative, collaborative effort with a team.

• Individuals have ideas. Teams have that many more ideas to build on.

• Individuals have a perspective. A team can provide a much broader, richer point of view from which to view a problem.

• Individuals make mistakes, have limitations. In a team, you have the opportunity to work together to overcome the limitations of any one individual.

It’s called synergy. The whole exceeds the sum of the parts.

But you don’t get that by taking a group of people and telling them what to do. To get synergy from a team, the team must be ultimately responsible for their own success or failure. If the team is simply doing what they are told to do, the one responsible for their success or failure is the one giving orders. That is why the Product Owner is a member of the team, and the team is responsible for architectural decisions. If you need the unity that having an architect brings, then let the architect be a part of the team, to help bring that unifying perspective without taking away individual accountability and contribution.

]]> http://www.irie-inc.com/2009/11/03/the-power-of-empowerment/feed/ 0 http://www.irie-inc.com/2009/11/03/keep-it-simple/ http://www.irie-inc.com/2009/11/03/keep-it-simple/#comments Tue, 03 Nov 2009 21:02:24 +0000 jarrowwx http://www.irie-inc.com/?p=47

Simplicity–the art of maximizing the amount of work not done–is essential.

This can be a hard one for really smart people. After all, if you know you WILL need something, why not build it now? Or if you know you MIGHT need something, isn’t it better to create it while it is fresh in your mind? The answer is NO, and for so many reasons.

• If you don’t need it now, it doesn’t add value now
  The goal is always to deliver value to the business. Something which won’t be used until later is adding no value to the business. Always try to consider an alternative way of breaking up the work to be done so that the parts delivered add value as soon as they are delviered.

• Future features may never make it into the product
  Realize that anything not accepted for delivery during this iteration may never make it into the product. Newer, better, more important features may be discovered (or legislated into existence) which make everything else you had planned to do obsolete or unimportant.

• Keep the cycle time short on pieces of code
  If you write a bunch of code that won’t be integrated to for another several weeks or months, then by the time you get around to doing the work of integrating them, the code will no longer be fresh in your mind. In fact, it may not even be you doing the work. When you finally start finding defects, it will be harder to debug and fix. Much better to do it all at once, whenever possible.

• A good architecture is extensible
  If your architecture is sound, you should be able to build the hollow shell of the components you need, get them talking to one another, and then start implementing the detailed behaviors that are required by those components on an as-needed basis. Forcing yourself to do this will help you to choose good architecture from the very beginning. It will also help identify hidden assumptions and problems sooner rather than later.

You choose how the product is built. Choose the path that gets you where you want to go in the fewest steps, overall. Do not be unnecessarily focused on the short term, but do not sacrifice the short term for the long term, either.

Continuous attention to technical excellence and good design enhances agility.

The faster you can adapt to changing conditions, the more agile you are as an organization.

A good design breaks out the functionality of the whole into independent modules that play well together. The boundaries of what each of these modules do is well defined. When (not if) something needs to change, it is clear where the change needs to be made. Just breaking things out into pieces doesn’t necessarily mean a good design, however. The test of ‘good’ is in how easy it is to figure out the ‘right’ place to make the change.

Do what needs to be done, and no more. But do it wrong today and you will likely need to do it over later. Resist the pressure to compromise on architecture. At the same time, resist the temptation to over-architect something. Make it flexible enough to do what you know you need to do, and no more, no less. It may take a little more time to come up with the ‘right’ architecture up front. But it will pay for itself soon enough.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is a measure of how well you have adopted Agile methodology.

• The Business and those that support them will break down the work into achievable chunks of work within a fairly consistent range of size and/or complexity.
• The work that is accepted for inclusion in a sprint should be defined and understood well enough to be able to commit to delivery.
• The team should have a good/consistent idea of the relative size of the units of work to be done.
• The team will commit to what they can deliver, and they will deliver it.
• The amount of work that the team delivers will be roughly the same from iteration to iteration.

Despite the complexity of some of the things that teams may set out to accomplish, no matter how monumental the project, Agile processes enable the team to consistently deliver units of work that add value to the business, time and time and time again.

Working software is the primary measure of progress.

Management loves metrics. Lines of code. Code coverage. Defect rates. Whatever they can think of. The belief is that these metrics provide the manager with the sense of involvement and awareness. They often use these metrics to try to make predictions. Unfortunately, what they don’t realize is how much the metric hides.

You may have 100% code coverage with your test suite. But that doesn’t tell you if your code does what the business needs it to do. Defect rates on a downward slope imply that the product is maturing and approaching completeness. What it may mean is that fewer and fewer testers are being engaged in the testing process, or fewer and fewer features are being delivered, without respect for whether or not you are actually near completion. Virtually every metric has assumptions that must hold true for the metric to have meaning.

But in reality, none of that matters! All that really matters is that the business is able to make money (or save money) using what has been built.

So what metric should the management care about? What has been delivered, working. The software being delivered is composed of features. Those features have value to the business, as determined by the business.

The only metric that matters is, how much value has been delivered in a form that can be used?

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

It is a well known fact that when two people are communicating, a lot more is being communicated than just the words.

• Words: There are the words being said, but there are also shades of meaning and emotional baggage that those words carry. Two different sentences with identical meanings can yield very different reactions.
• Tone: The inflection that a word is spoken with can help to indicate which if any of the baggage that words carry apply to the intended meaning. It can also help to resolve any ambiguity in meaning.
• Gestures: These can communicate concepts not captured in the words, such as size, distance, direction, speed, tempo, and other modifiers.
• Pictures: Drawings on a white board can communicate relationships, implications, all kinds of information with a quick and simple scribble.
• Body Language: The emotional state of the participants is communicated through body language.
• Vibe: Vibe is the emotional effect that the sum of the parts has on the participants. It is influenced by word choice, tone, and body language, but there are also less generally recognized factors involved, such as pheromones. Who knows how many other things that are not scientifically recognized may also be involved.

The point is, the more of these information channels are present in a communication between individuals, the less is lost in translation from person to person. As soon as you introduce technology to take the place of being in the same room, something is lost.

Email has to be the worst. Words, still possessing all of their emotional baggage, are devoid of the cues that help us resolve the emotional ambiguity that they contain. Emoticons help, but only a little, and rob it of professionalism. Email is great for sending information to a person without requiring them to be interrupted. It is great for keeping a record of what was decided. But the best use of email is to communicate the need for face-to-face conversation.

Documents are a step up, since they can include pictures. But they tend to lack interactivity. Chat is only a small step up from email. Phone calls are good, but conference calls are murder. Conference calls with a shared screen are better, but its so easy to tune out. Telephone call quality has an impact on people’s willingness to listen that should not be ignored.

Bottom line: Don’t fool yourself. Technology is no substitute for getting people in a room together with a white board. If it is important that everybody be on the same page, get them all in the same room.

Learn more

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Expect a person to fail, and sooner or later they will. If you have a process that assumes incompetence, designed to protect the company from mistakes, then you are enabling incompetence to persist in your organization.

Expect a person to succeed, treat them as if they will succeed, give them what they need to succeed, give them an environment where mistakes are learning opportunities, not failures, and they will almost always succeed. Those that can’t will be readily apparent, and can be removed from the team, if they don’t remove themselves.

What do you need to provide to a person and/or a team in order to help them be successful?

• Training. If they don’t understand the process, they can’t follow the process, and success will be harder to come by.
• Tools. If delivery matters, the tools needed for delivery matter. Get them what they need to succeed.
• Leadership. If the business doesn’t provide direction at the pace that the team needs it, the team / process will fail.
• Empowerment. A team that is just following orders will gladly do as they are told, even if it is wrong. Make them responsible for delivery by empowering them to deliver, give them ownership over what they are delivering, and they will let you know if they see problems in what they were asked to do.
• Protection. Protect teams and individuals from the things that lead to failure, such as being spread too thin by too many meetings or projects, or spending an excessive amount of time justifying their existence through reporting.

This list is not exhaustive, of course…

Business people and developers must work together daily throughout the project.

The responsibilities of the business owner are to do just-in-time planning, filling in the details in the backlog sufficiently that the team will be able to understand the work that needs to be done in the next sprint. They define what it means for a story to be completed. In addition, they are to serve the informational needs of the team, interfacing with the end users and the subject matter experts.

During the course of development, questions are bound to arise. Given a choice of going one way or another, if it is a technical question, then it is up to the team. But if it is a domain or a business choice, then the Business/Product Owner needs to make that decision. For that reason, the the business owner should expect to be working with the team on a daily basis. They should make themselves available to them, perhaps even co-locating with them. They should be proactive, cultivate a culture of questions and feedback from the team.

An all too common mistake is to have a business owner that shares his time between projects. The problem there is, all of the teams suffer as a result. While the company may be paying one less salary, they are getting less productivity out of 15 or more people. Not a wise trade-off.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The goal of every sprint should be to create something that gives the business a sense of perspective, a frame of reference to use to direct future activities. What you deliver needs to work, at least in some respect or with some limitations, in order to offer the business that sense of perspective. If what you deliver can not be seen by the business, it adds no value.

“But it adds value to the development effort!” you might be thinking. Sure, assuming that your understanding of the direction that you need to go is correct.

Note that you are not simply taking a traditional development project and breaking it into 2-week chunks of work. You are creating a functional piece of software. It is all too easy to fall into the trap of breaking things down functionally, and then trying to map your functional decomposition into a backlog. Too often, you end up with pieces which can not stand alone, which do not deliver value to the business. The business can’t prioritize those kinds of things.

The problem is diving too deep. It’s so easy to do, too. You want to understand the problem, so you divide and clarify, divide and clarify, and at some point you magically and invisibly have gone beyond what you are trying to accomplish and have transitioned into the how of accomplishing it.

Therein is the secret of making sure your backlog includes only items that add value: They only tell you what it must do for the business, it does not specify how it is done. Review every user story, and ask yourself: “Is this telling me what the system needs to do, or is it telling me how the system works?” If it is the latter, change it to be the former. If you can’t, then you probably broke down the functionality too far, and that story needs to be rolled into another one that it supports.

It takes discipline, and maybe even a shift in ways of thinking, but you need to deliver something that “works” every time. It may be a mock-up or a prototype, it may not do everything it needs to do when initially delivered, but it is something that the business can see and wrap their brains around. The purpose of this is to empower the business to give their guidance sooner rather than later, and save everyone the frustration of wasted effort.

“But isn’t a prototype a waste of time?” Not really. Build it right and you can simply refactor it as necessary to make it into what it needs to be. And in the worst case, if you have to throw the whole thing away, you still ended up with valuable understanding of the problem, and that all-important frame of reference for the business to guide forward progress.

So, deliver working software. But deliver it often. Very often. Here’s why:

• If you have a term paper due in six months, what is the likelihood that you will finish it tomorrow? What is the likelihood that you will do the bulk of the work the night before it is due? The longer the sprint length, the more this tendency might rear its ugly head.
• The bigger the sprint backlog, the more overwhelming it can feel, whether there is any reason for it or not. So, the longer the sprint, the bigger the sprint backlog, the harder it is to focus, for some people.
• The shorter the duration, the sooner the business can give its feedback, the more Agile you become.