Your Daily Standup Should be Boring

If you are a Lean/Agile team you probably have a daily standup / scrum that you are trying to complete in 15 minutes or less. You might even be “standing up” in that effort. You are most likely failing, and your average standup runs for half an hour or longer. And I’m not even counting the “meeting after the standup”.  You have tried various techniques the plethora agile books prescribe, and it does work for a week or two but then just falls back to the old pattern.

Have you wondered why?

The key is to first understand why you even need the standup in the first place. Then work assiduously to eliminate every single reason to have the standup, but not stop it.

You are then likely to find a couple of things:

· There’s not much to talk about at the standup. In fact, it’s probably boring
·   Your standups are getting done in 15 minutes or less

This is a great state to aspire – a non-eventful standup without drama.

How do you get to this stage?

Let’s first look at what’s happening in the standup today. What topics are being discussed? Very likely:

• Status
• Problems
• Solutions
• Decisions

So, that’s what’s eating time in the standup. The crucial question to ask is why is this coming up in the standup? Obvious answer – because people didn’t raise it earlier. Why didn’t they raise it earlier? Your team should be raising the issue when the event happened. Not wait till the standup.

Thus, the vital improvement to be implemented here is to raise issues when the event occurred. Not hold back till the standup which is usually a once a day event.

Why is this important?

If you are thinking that we are looking to save a few minutes at the standup – that’s not the driver. Although, that is desirable, that’s not the main goal. The real cost of an extended standup is not the extra minutes, but:

·        Disruption to the flow by not resolving issues soon as they occur
·        Cost of delay by waiting for the standup

And if you put in processes in place to resolve problems when they occur, empower people to make decisions quickly, there’s going to be very little to discuss at the standup. Your standup might be boring. A standup that’s boring for the right reasons is a good thing.

Work hard to make the standup boring. But don’t eliminate it. What remains to be discussed in the standup now is probably what should be discussed in the standup.

Why your company may need OKRs

OKR? What's that?

Glad you asked. It's a goal setting framework. It stands for "Objectives & Key Results". Here is an example:

Objective

Grow company revenues

Key Results

1. Hit global annual revenue of $150 million
2. Achieve 100% YOY sales growth in North America
3. Increase the average deal size by 25%

Notice how it has two key elements?

Objective: Your goal, your dream, your vision. Its What you want to get done

Key Result: A very specific, measurable way to show How you are going to get it done

That looks like an MBO! I've been doing them for a while and I don't think I like them. I'm outta here!

Wait. It is built on MBO's and KPI's but there are important differences. Tweaks really, but very key ones tuned to suit contemporary management and product development practices

But first, some history

OKR's were first implemented by Andy Grove at Intel. He built upon the concept of MBO (Management by Objectives). Then John Doerr, who watched Andy use it at Intel to great effect, introduced it at Google, and helped Google become Google. And that's how OKR's became famous. A lot of companies use them now. And Google still uses them.

So, how are OKR's different from MBO's? 

They differ fundamentally in three ways - Purpose, Transparency and Cadence.

	MBO	OKR
Purpose	A method for employers/supervisors to manage their subordinates by introducing a set of specific goals. The goals must be achieved 100%. Used to review/reward the employee during the performance review	A system to prioritize, communicate and get everybody to contribute to what matters most. The goals are stretch goals and employees are not penalized for not meeting them 100%. OKR's are typically not the basis for a performance appraisal
Transparency	MBO's are confidential. They are between the manager and the employee	OKR's are public. Everybody can and should see everyone else's OKR's
Cadence	Set yearly. Very waterfallish in nature	Set monthly/quarterly. Lean/agile in nature

Okay. Why should my company or team have OKRs?

Here are 10 Reasons:

1. It's a communication tool. It's a system to communicate what's important to the company (or team) and what's not. Now, if you are the CEO or leader of team, you know that effective communication is one of the hardest things to do. This helps. A lot
2. It promotes transparency. Ever wondered what matters to your CEO, company, a key executive or team? Now you know - because everyone's Objective, Key Results and grades are visible to all.
3. It empowers. Now that you can see everyone's OKR's, you can choose to help. Especially if it's in your area of expertize. Your objectives don't have to be handed down Top Down  anymore. You can add your own. And sometimes, your objectives are so cool, that they may become a department or company objective in the near future. How empowering is that? You just made a difference!
4. It's aspirational. OKR's are stretch goals. Achieving 65% of the impossible is better than 100% of the ordinary. Even if you fail on a stretch goal, you are bound to have learned something valuable. They are like little moon shots..
5. They promote innovation. Sure, you can have "business as usual" objectives. But you can have aspirational OKRs too. They give you permission to fail. And if you haven't failed recently, you haven't tried hard enough
6. It engages your team. How? Just like you can have individual OKR's, you can have team OKRs too
7. It sets direction. You can tell where your company is going. It's like a North Star, a beacon - constantly guiding you.
8. It prioritizes. You know what matters and what doesn't. Prioritization is key to execution.
9. It sets alignment. Now that you have direction and priorities, you can all work on the same thing. This leads to better outcomes
10. It's data. Good OKR's provide objective, quantifiable data points about what's being done and how well it's being done. If you are a Data Driven company, you wouldn't want to miss out on this key metric

And they solve world hunger. OK, now I'm exaggerating. But if we do want to solve hunger, we should start with OKRs. 

Seriously

Top 10 Kanban Practices

If you are a team that's been practicing Kanban for a few months, here are a few practices that will make your team more productive.

1. Stop starting, Start Finishing. Help your team get a story/feature done, rather than add a new one.
2. Follow WIP limits. Seeing “RED” on your board should cause discomfort and move the team to fixing it
3. Work from right to left. If you have the skills, pick the story on the right of  the board and help move it towards DONE. Remember, organizations make money when work is done
4. If a card is spending more time in a column than it should, offer to help . Do not wait for a manager / team lead to bring this up. Also, do not wait for a standup to bring this up. Define a policy in your team on what should happen if a card is spending more time in a column.
5. If a task/process is not adding value, eliminate it. Do not wait for the retrospective to bring it up.
6. Update the board to reflect the current state of work at any time (position on the board and who’s working on it). Do not wait for the standup to move a card. The board is a communication tool and it needs to communicate the true status at all times
7. The standup is not a “status report” - the board already conveys the status. Discuss roadblocks / improvement ideas rather than a routine discussion of cards on the board
8. Have team members take turns running the standup. This will cause them to pay attention to what's going on in the team.
9. Gradually, look to reducing the WIP limit, thus promoting more collaboration.
10. Celebrate what got done yesterday.

Why your company may need a Hackathon

A Hackathon is a creative problem solving / focused innovation exercise where people in your company will take a fixed time-out from regular work to solve problems or suggest new ideas. Participants will form small groups and code solutions (prototypes). At the end of the Hackathon teams will demonstrate  the solution they've "hacked" together.

Why does your company need a Hackathon?

The hackathon is a forum to unlock the creative potential in your team members.

If you are a knowledge based company - and who isn't nowadays - the ability to innovate is key to your future. The day to day tasks  probably keeps your teams focused on execution but don’t offer much opportunity to tap into their creativity. The idea is to give your teams the freedom to step outside the constraints for their day-to-day and see what they can come up with when the ball is in their court. They'll be working on projects they're excited about, not building something because that's what they've been told to do.

As many companies have discovered, it's pretty amazing what can done in a Hackathon. Often these implementations / ideas turn up to be new business opportunities. However, events like these are unpredictable.  There are no guarantees, with failures as likely as success. 

A hackathon is not a panacea but instead should be part of an overall strategy to spur innovation. 

The investment is small and the reward is potentially huge.

Other Benefits:

• It's a great team building exercise that also results in tangible outcomes for the company in terms of solutions and new business opportunities.
• It sends a clear message that you value innovation
• Creates positive energy and helps morale. It’s also a learning experience
• Unlocks the creative potential in our team members
• Helps retain talent. And even helps attract talent (with so many companies doing Hackathons not doing it makes us "uncool")

How it works

1. Employees suggest and brainstorm some ideas
2. Employees sign up for the short listed ideas and form small teams
3. Each group is given a fixed time to come up with working code
4. At the end of the Hackathon, every group demos their work to all participants as well as management

Some interesting links on Hackathons

http://www.wired.com/2012/02/ff_hackathons/all/1

http://mashable.com/2010/06/30/hackathons/

http://techcrunch.com/tag/hackathon/

The Feed Forward Loop - A learning process

The Feed Forward loop is a process to become a “Learning Organization”. Successful teams and eventually successful businesses are those that learn the most in the least time.

I call it the “Feed Forward Loop” because it’s purpose is to fuel the next cycle. It’s a forward looking cycle that aims to deliver scientific learning in every loop. Every initiative that an agile team starts must be targeted towards increasing learning in the shortest possible time. For example, you should aim to learn more about the customer, the business, the market, etc. As you know, learning is best accomplished by doing. The Feed Forward Loop facilitates that.

There are four steps in the loop:

1. Hypothesize

State your assumption for the initiative that you are about to launch. What do you intend to achieve? What are your success/fail criteria?

2. Test

Devise a method to test the initiative. 

3. Measure

Measure the outcome of your test. Did it pass or fail? Did it validate your hypothesis?

4. Learn

This is the key to the initiative. Whether the initiative succeeds or fails, there’s always lessons to be learned. Use this learning to kick off the next cycle.

Kanban: Assets and Liabilities

The next time you look at a Kanban board, pretend to be an accountant. Look through the eyes of an accountant. You'll probably see two columns like most accountants do - Assets and Liabilities.

Don't see them? 

Work that is "Done" or "Released" is an Asset. Companies make money when work is done. You'll probably find this on the right side of the board.

Now look to the left. Those are your liabilities. All this work that's "In-Progress" - they are liabilities. You can be proud of them, but they are not making you money. In fact, it's quite the opposite - they are burning money.

So what do you do with this knowledge?

Start converting your liabilities into assets. Don't add new work (i.e. increase liabilities), instead create more assets (i.e. complete work). Work from the right side of the board.

Stop starting, Start Finishing.

The Daily Kanban Stand-up

Many teams transition to Kanban from other agile processes. And often,  they conduct the daily stand up just like they used to in their previous process. Since Kanban is an evolutionary method, in the beginning that's fine. However, very soon you'll find that changes are necessary.

Teams new to Kanban use the stand up like a status meeting - often taking turns to update the team on the status of  their "tickets".  Or, they keep it very Scrum like, typically answering the following questions, with some variation,  in a round robin format:

1.  What did I accomplish yesterday?
2.  What can I commit to doing today?
3.  What are the impediments in the way?

While that may have been appropriate for your past agile process, of the three questions, only the last one is relevant in a Kanban stand up.

(1) is unnecessary because the cards on the board tell the story. The WIP (Work in Progress) is visual.

(2) is irrelevant because work will take whatever time it will take to get done. Committing to accomplishing the work will not necessarily make it faster. Often, that leads to heroic effort. In addition, the focus on completing the work that has been "committed" to can actually come in the way of continuous improvement.

So,  what should we discuss in the stand up? I'd suggest:

1. Impediments: What's impeding us?
2. Flow: What's the flow like?
3. Kaizen - or "Continuous Improvement": What can we improve?

Let's take a deeper dive into these questions.

What's impeding us?

Impediments are in the way of getting work done. Impeded work items should be marked visually on the board - usually with a pink sticky on top of it. Team leads or managers should focus on getting these impediments removed as quickly as possible.

Note that you don't have to talk about which item is impeded - that's obvious from the board. The conversation should be around resolution.

What's the flow like?

Kanban looks at software engineering as a flow problem.  The board will show where the bottlenecks are and therefore what's preventing the team from accomplishing more. The conversation should be around smoothening the flow and what actions the team can take to relieve the bottlenecks.

What can we improve?

Kanban is an evolutionary method. It's success largely relies on a mindset that's looking to constantly improve. These do not have to be big changes and can be a series of small improvements. Having a brief conversation on this topic everyday will make it clear that it is everyone's responsibility to make the process better.  When suggestions for improvement come from the team (rather than from managers), there is greater ownership and more likelihood of success.

These are the core questions. Here are some additional practices for a successful standup:

Ensure the board is up to date before the stand up

Many teams also use electronic tools along with a board. It is important to keep the two synchronized. Before kicking off the stand up, ask the team if the board is synchronized.

Celebrate the small victories

The done column on  the board should ideally have two parts. Work done for the week (or an appropriate time period) and work done since the last stand up. You can now see what got done since yesterday. Call attention to what got done. Recognize the effort, if only for a moment. Bring your hands together. Yes - applaud and cheer.

Celebrate small victories and energize the team.  And move on.

Change facilitators

Encourage different team members to take on this responsibility. When you facilitate, you'll get a different perspective of the process. You'll also take more ownership and funnily enough, suggest more improvements.

End the stand up on a high note

 If you have a team song, team dance, a war cry - do it. It'll always elicit a laugh and keep good cheer.

 I'd encourage you to try these practices and improve on them. You should bring in your variations to the stand up around the core practices.

Remember - the goal is to continuously improve.

Kanban Introduction

Kanban Blog

WIP limits - The magic sauce in Kanban

A software development process can be viewed as a queuing system. Little’s law states:

Lead Time = Work In Progress / Throughput

Lead time is the time that a work item (represented by a card on a Kanban board)  spends in a system in various work states. We want to reduce that, so we can get more work done i.e. increase throughput. As you can tell from the equation, reducing WIP (work in progress) is one way of achieving that. 

Less is more

We've all heard that and have certainly experienced that. That's an earthy way of stating Little's law. We can get more done, when we are focused and working on fewer things.

Why?

We are not wired to work on multiple tasks at the same time. When we say we are multitasking, we are really switching our attention from one task to the other i.e switching contexts. Context switching is a waste. Studies have shown that with every additional task taken up there’s a 20% loss. If we are working on three different tasks, we’ve lost almost half the time in just context switching.

Grandma was right - less is more. But don't tell grandma that. Not unless you want her to limit you to just a couple of  freshly baked cookies instead of the usual half dozen. 

Ok, we should limit WIP.  But how do we determine the WIP limit?

We experiment.

If we set the limit too high, we will continue working on multiple tasks. If we set the limit too low, we may cause bottlenecks and affect the flow of work in the system.We want the WIP limit to be optimal so we can have a smooth flow.

But it’s not a science. The board will tell you. 

There are advantages to starting with a lower WIP limit

Yes, they’ll cause starvation and pain. But lower limits will expose potential problems in the system. The industry uses the analogy of the WIP limit with lowering the waterline. Lowering the waterline exposes the rocks (i.e. bottlenecks and constraints).  When the problems are exposed, the team can work to remove the bottlenecks and constraints until the work flows smoothly again. 

And so on and so forth.

It creates slack

When everybody is working  all the time, there's not much time to introspect, retrospect, experiment, innovate or even  have lunch. As a rule of thumb, lead times go up when utilization crosses around eighty percent.  High utilization is not good. We've probably experienced this when the highways begin to fill up with cars or when the CPU on the computer gets toward its capacity.

How do we create slack?

We could hire additional members on the team. Imagine going to the folks that handle the purse strings and telling them that we want ten developers in the team but we only want to keep eight developers working because we've heard that utilization  at above eighty percent is not good. Good luck with that :)

Or - we could apply WIP limits

If we have a team of ten and we've put an overall WIP limit of 8, and assuming only one person works on an item at a time, we've taken away work from a couple of developers. In other words, we've intentionally created slack (or  excess capacity). And slack is good because it will allow these two "idle" developers to do a few things such as pair up with other developers or help resolve issues at bottlenecks.

And funnily enough, this will help get more work done.

It's an enabler for a "Pull"system

A pull system is one where the downstream process pulls in work only when it's ready to process it. This will result in producing only what's needed, transferring work to a work station when needed and reduce inventories i.e. it will help result in a lean outcome.

When we have WIP limits, we cannot take on work unless  we have a "slot" available on the work station. We are consciously defining our capacity to take on work. Imagine if we did not have limits. Work would be "pushed" to us by the upstream process - whether we were ready or not. And  most likely, it would just wait  to be acted on. That's a waste.

WIP limits make Kanban a "Pull" system.

It's an enabler for Kaizen

It's not that we don't want to improve, but it's usually that we don't know where to start. Or what our bottlenecks/problems are. Lower work limits are a great enabler for continuous improvement (kaizen). When you run into the bottleneck, resist the temptation to immediately raise the WIP limit. Get a conversation started in the team and look to resolve the bottleneck. 

Pound the rocks to submission. And if you still have a bottleneck, raise the limit to enable flow.

Trust the board. The board does not lie.

BDD is not about tools

Many teams practicing BDD assume that the tool is the process. A lot of chatter is about: 

• What BDD tool (or framework) should I use?
• How should I use that tool?
• Is tool X better than tool Y?
• Etc., etc, etc. 

So much noise, that I’m afraid the intrinsic value of BDD is lost. Just because you are using a BDD tool, doesn’t mean you are practicing BDD. The tools are important, but not absolutely necessary. You could get a lot out of BDD without a tool. Here’s what I mean.

BDD helps build “Software that matters” 

In order to do that, you should capture requirements as behaviors resulting in a list of “behavior specifications”. In fact, that is what gathering software requirements is all about. You should define what the software should do (i.e. behavior) and frame it in the context of the business value.

But that’s hard.

Waterfall teams tend to write verbose documents, that developers find hard to understand. Agile teams err on the opposite side, writing terse user stories that often do not have enough information. BDD helps bridge the gap with the notion of User Stories that have two components: (a) Narrative and (b) Scenario.  The scenarios are the acceptance criteria and provide examples of how the software should behave. It helps to illustrate the narrative, providing a concise, yet vivid description of the expected business outcome.

You don’t need any new tools to do this.

It provides a language to document the behavior

The narrative is written in the format:

As A [role],

I want a [feature],

so that I [benefit])

The scenario is written in the format:

Given [context]

When [even]

Then [outcome]

This is a very structured way to express behavior.  “Given” describes the context or state of the system, “When” describes the user action or state transition and “Then” describes the outcome or expected behavior.  This expression almost feels like code. Yet it is in a natural language and more importantly, is in the language of the stakeholder. Because of the reduced ambiguity, you are likely to get what you are asking for. Especially, because you are also kind enough to tell the programmer/QA Analyst why a feature is required – a very important aspect of software requirements that is often ignored. Just adopt this format for your software requirements.

You don’t need any new tools to do this.

But it’s more important to discuss the behavior

Don’t just define behaviors, discuss them. Leverage the “Power of Three” i.e. the Business Analyst (a proxy for Customer or Product Owner), the QA Analyst and the Programmer in defining behavior. You can start with having the Business Analyst write the narrative and scenarios for the user story. But be sure to have the QA Analyst and the Programmer review the user story. Good QA people can elaborate the user story. Programmers can keep the specification realistic. Discuss it together, even if only for a brief time. These three stakeholders bring very different perspectives and expertise to the table. You’ll find that the scenarios get fortified with better acceptance-tests, including behaviors that were not originally considered. At the end of the conversation you will also have a definition of “done” for the user story.

You don’t need any new tools to do this.

It’s about baking quality in

Many defects occur because the requirements are ambiguous and subject to the programmer’s interpretation.  BDD fixes this through the scenarios with their rigid grammar. The scenarios provide the cues to the programmer to build the right features.  Defects also occur because the behaviors are not completely defined. This can be fixed by using the “Power of  Three” to inspect the user stories, discuss them and finalize them. This may take some time, but the investment will pay off. As the Toyota Production System says, “Inspection to find defects is waste. Inspection to prevent defects is essential”.

You don’t need any new tools to do this.

Engage the stakeholders

Leverage the “Power of Three” at every opportunity. Include the Business and QA analysts in the design and architecture conversations. Encourage the Programmer and the Business Analyst to review the test cases. When stakeholders, especially those that are more “outside” than “inside”, get involved in design conversations, they are more likely to drive a better understanding of the need and therefore influence the behavior.

You don’t need any new tools to do this.

However, you will need the BDD tools if…

You want to create “Executable Documentation” i.e. you want to record the behavior specifications in the BDD grammar in a BDD tool. Typically, these tools generate skeleton code, against which you write production code following TDD practices. Similar to the XUnit tools, initially tests will fail, and when the behavior is implemented correctly, the tests will pass.  This will provide traceability from the code to the business value.  More importantly, if you are disciplined, you will write just enough code to meet the behavior, thereby reducing waste.

In conclusion

A lot of the intrinsic value of BDD can be realized by:

-  Applying its User Story format

-  Documenting requirements using the recommended grammar

-  Leveraging the “Power of Three” to bake quality in the process

-  Engaging stakeholders to ratify and discover new behavior

And all of this can be done without BDD specific tools.

If you believe you are already following these best practices, then it's time to reach for the BDD tools. But not until then.

Stress in Agile teams

People working in agile teams sometimes complain that stress levels are higher in agile projects. Now, we all know that it is not supposed to be so. After all, don't agile projects distribute work more evenly for the duration of the project? Aren't agile teams supposed to be self organized and responsible for signing up for an appropriate load of work in a sprint (can't even blame management now)?

Agile experts are quick to point out that the increased stress, if that's even true, is most likely the fault of the agile coach / scrum master. Don't blame the agile methodology, they say. But then, there have always been good managers and bad managers and there certainly are good agile coaches and bad agile coaches. In many teams, the managers have now become scrum masters or agile coaches. When the same team, under the same manager that was practicing waterfall or iterative development is now practicing agile and is complaining about additional stress, could there be some truth to the statement?

Let's examine possible reasons for the stress and potential ways to mitigate them.

The Daily stand-up: This is the heart of many agile processes. This is also a potential stress point. Think about it. Day after day, you are asked to give an account of yourself in front of others. What did you do since your last stand-up? What do you plan to do today? Like it or not, you are subjecting yourself to intense scrutiny. There's no place to run and no place to hide. You cannot help wondering what your team mates think of you. You cannot help comparing yourself to Joe who always seems to get more done in the same time.

How to mitigate it: 
Emphasize to the team that skills and experience vary between individuals. Some are more skilled and experienced than others and may even be earning substantially more. Therefore, it is natural that they will produce more. Do not compare yourself with the performance of others. Just do the best you can.

Commitment:
 In agile, as in life, it's the many small promises that we make that adds to the pressure. In an agile process, specifically in the daily stand-up, we are making promises everyday. We call them commitments. It's human nature to want to meet those commitments. We are essentially honest people and we want to live up to our promises. Until we fulfill that promise, it's hanging over our heads like the proverbial sword of Damocles. And if we fail to keep the promise, we feel guilty. Even, if it's not entirely our fault.

How to mitigate it: 

Don't not use the word "commit". Instead, say "try". Don't say "I commit to do X". Instead say, "I'll try to do X". It's a subtle but important difference. Notice how there's no promise to deliver? Does that mean you are going to work any less harder? No. Remember, we are honest people. Our teams trust us.And we will do what we can to complete X. 

But we did not commit.So there is no expectation tomorrow that it will be done.We'll sleep better and perhaps even make it home in time for dinner.

Estimates:

When teams or individuals estimate tasks, they are implicitly committing to the hours. When we commit, we take on stress.

How to mitigate it:

Do not ask for estimates. Instead, attempt to "right size" the tasks using techniques like T-Shirt sizing. Measure the time taken to complete the task from the time it is started. The task will start when it does and complete when it does. As the team gathers these metrics they will also become more adept at "right sizing" the tasks. The eventual outcome is a steady velocity for the team.  And since the team is not providing estimate that they have to commit to, the stress is also less.And when the team is less stressed, they produce more.

Conclusion
Agile processes introduce stress in many subtle ways. Some of these are an outcome of the high visibility and transparency of the methodology - the very techniques that make agile so successful. This stress is not introduced intentionally - rather it is an unintended side effect. Being aware that the stress is real and tangible can help us mitigate it.

Unless we acknowledge it, we cannot manage it.

When Agile becomes Rigid

Agile teams are supposed to be agile. Yet, there are agile teams run by over zealous agile coaches, who in their quest to become agile have actually become rigid. In fact, very rigid. If you see the following signs, you are in one such team:

• It is the Agile coach's way or the highway. He/She will parrot prescriptions from various agile books on how it should actually be done. Forget the manual, coach. True agile is not supposed to be prescriptive. Good ideas can come from anywhere - include the team by your side that's still (Oh, my God!) practising iterative/waterfall.
• The agile coach will  not let a member of the team to participate in other important meetings/discussions in the organization, because "it will affect the team's commitments to the sprint!". Yes, the sprint is important but the organization is more important.
• You feel like you are followinng a cult rather than a software development methodology.
• The team is apparently "self organized" - or so the agile coach says. Repeatedly. And yet, all major decisions are from the agile coach.
• It's easier to stop the earth's rotation than to change the schedule of the Sprint ("we have committed these deliverables to the customer"). It doesn't matter that there are existing customer who probably want a fix urgently. Oh no, nothing can come in the way of the Sprint!
• All  the fun at work is lost. It's all about commitments and not letting your team down. And yet, ironically, there's a lot of talk about "the team is a family", "active socializing", "protecting the team member from context switching". etc. You didn't hear such talk in your "waterfall" team and yet you felt like it was a family. Strange, eh?
• Life is a series of Sprints. You are reduced to a Sprint Monkey going from one sprint to another. Even your schedule at home, revolves around these sprints ("I don't have time to throw the trash, dear. I'm in the middle of a sprint!").

If you are in one such team, remind your agile coach about agility. It's not enough to follow agile practises - you actually need to be agile.

Stop finding Defects !

Yes, please. Let's focus, instead, on "Preventing Defects".

We need to develop software faster and with better quality than ever before. We cannot afford to have an extensive "bug fixing" cycle. Finding defects towards the end of the software cycle is expensive. We all know that and yet many teams continue to do just that. This is perhaps the only industry where we tolerate that process and devote extensive time in the development cycle towards finding and fixing them. We wouldn't dream of a process like that while building houses or cars. Or even while cooking a meal at home. So why do we allow that while building software?

Could it be ignorance? Or complacence? Neither is acceptable in this day and age.

I'd like to suggest that we have tools and techniques at our disposal that will go a long way towards preventing defectings. What is lacking is belief that it's possible. Try it in the small and the belief will come.

Try BDD (Behavior Driven Development).

"Finding Defects" is an industrial age activity. "Preventing Defects" is a knowledge era activity. And in case you didn't notice, we are in the knowledge era.

BDD is more than “TDD done right”

BDD is more than just doing TDD right. Beginners in TDD struggle to understand that TDD is really about design and not testing. Similarly, newcomers to BDD may find it challenging to appreciate that BDD is also about collaboration between stakeholders and not just software behavior. You will find discussions on the internet on “BDD is TDD done right”. That’s certainly true, but there is much more to BDD. We will soon look at the additional value BDD offers, but first let us list why people think BDD is just TDD done right. 

1. TDD captures behavior or intentions just like BDD. You write a test case upfront to capture a behavior. However, the vocabulary is all test based so this is confusing. BDD fixes this by using the right vocabulary. Therefore, BDD is still TDD – but better. 
2. TDD captures low-level requirements (usually at the class/method level). BDD captures high-level requirements. Therefore, BDD is still TDD - but at a higher level.
3. BDD and TDD result in a suite of tests that we can run as a regression suite. Therefore, BDD is still TDD.

What then does BDD offer that is not in TDD? The value is largely in the collaborative process for defining requirements and the grammar and structure used for capturing them.

BDD captures requirements as user stories. A story has two parts – a narrative and scenarios. A requirement is not complete until it has both. We write Stories in BDD with a rigid structure. We write a narrative using a Role/Benefit/Value grammar and scenarios using a Given/When/Then grammar. Following a rigid structure like this can help adoption of a common vocabulary that leads to unambiguous requirements.

However, the benefit goes beyond that.

The crucial value that BDD offers is the process for creating the user stories. User stories are developed collaboratively by the key stakeholders – the Product Manager (or customer or Business Analyst), the QA resource and the developer. This level of collaboration results in:

1. Developing features that truly add business value.
2. Preventing defects rather than finding defects. Think how much easier it is to write code when you have scenarios that exemplify the positive and negative behaviors and make the intention transparent to the programmer.
3. Bring QA involvement to the forefront. This is great for team dynamics because in many agile processes QA personnel feel ignored.
4. Define executable, verifiable and unambiguous requirements.
5. Provide a better definition of “DONE” for agile development. 

However, the benefit goes beyond that.

BDD also helps you write “Software that matters”. What does this mean? Think of it as writing just enough code to meet a business requirement. You are probably thinking, “I could do that with TDD too”. Consider this. As you are writing Junit tests cases, is a stakeholder (Product Manage/Business Analyst/QA resource) with you? Probably not. Have you ever written code (probably excellent code, perhaps even following TDD practices), that was not required? Probably yes. You may not have shipped it, but you probably wrote it, found no use for it and deleted it. That is a waste. When you follow BDD, you are less likely to do this. You will reduce waste.

How can we write “Software that matters”?

The best way to do that is to leverage BDD and TDD. Here is an approach:

1. Write requirements as user stories using the BDD grammar/structure. Do this collaboratively with the key stakeholders.
2. Enter the User Stories (feature + scenarios) in a BDD tool.
3. Write code to map the User Stories to tests.
4. Write production code using TDD to make the tests pass. 

As you can see, BDD is not just TDD done right. You could use just the vocabulary of BDD to improve TDD but that would be like using only some of the benefits that BDD has to offer us. When we use the the strengths of both these techniques we will have “Software that matters” along with “Software that works”.

  

That is the promise of BDD.

Agile is not about speed

Studies have shown that agile methodologies shorten the software development cycle. Naturally, many assume that agile is all about speed. This is quite far from the truth.

What's the usual cause of delay in software projects? Quality. Or more accurately- lack of it. For example:

• Poor quality planning leads to project delays.
• Poor quality requirements, leads to poor implementation
• Poor quality implementation leads to defects which leads to delays
• Poor quality testing, leads to disaster

Agile methods infuse an intense focus on quality at all these levels.

• Planning is kept simple and straightforward to achieve sprint goals. Usually, the entire team participates in planning.
• Requirements are reviewed by all stakeholders and are kept minimal to achieve business value. The focus on business value ensures that only the “Minimal Marketable Features” make it to the sprint. Good requirements ensure that minimal code is written. We all know that the highest quality code is the code that isn’t written.
• Peer reviews, pair programming and Test Driven Development results in higher implementation quality.
• Quality is baked in at all levels. QA focuses on preventing defects rather than finding them.

A team that follows all this rigor will actually be writing fewer lines of code per day than other teams. Per conventional measurements, these teams are slower! However, the quality of the artifacts (all artifacts – not just the code) is much higher because it receives intense scrutiny. Enforcing quality at all levels has a happy side effect of speeding up projects. If you want to deliver more, and if you want to deliver it faster - slow down and focus on quality.

That's the essence of Agile methodologies.

Why are there so many Agile Coaches?

Makes me wonder.

Agile development must be hard. Why else would there be so many Agile coaches? When people were doing waterfall, I don't think there were that many "Waterfall Coaches". Think about it. How many of your contacts in the software world were "Waterfall Coaches"? None of my personal contacts were coaching waterfall. On the other hand, I know of at least half a dozen who are in this business - either fulltime or part time. And I'm running into many strangers who are Agile coaches. Or at least want to become one.

For a methodology that is supposed to be simple, why are there so many coaches? Perhaps it is not simple. Agile is supposed to simplify but that's not the same thing as being simple. Perhaps the highly adaptive nature of agile methodologies necessitates a coach.

Essentially - what does an agile coach do? If you are a team that's already practicing an agile methodology, she'll probably take a look at your methods and suggest improvements. Should I use the word prescribe changes? Funny. We choose a methodology that's not prescriptive for its ostensible benefits and then we hire a coach to prescribe methods.

The Rise of the BAQA ("BaaKwaa")

The role of the Business Analyst (BA) and Quality Assurance Engineer (QA) as we know it is changing. As agile methodologies become prevalent, they appear to have an overlap. I think of a person performing this new role as a BAQA (pronounced BaaKwaa). The need for people in agile teams to wear different hats is spurring this development. In recent times, this has received a boost with the development of frameworks supporting Behavior Driven Development (BDD) and Acceptance Test Driven Development (ATDD).

Agile teams, and in particular teams following BDD/ATDD, write user stories in place of verbose software requirements. The user story captures the essence of the requirement expressed in a "Role/Feature/Benefit" grammar. Subsequently, acceptance criteria are written as "Givens/Events/Outcomes" to exemplify the requirement. Together, they completely define the business requirement.While the user story requires a Business Analyst's skill, the acceptance criteria requires a Quality Assurance Engineer's skill. Essentially, we now have a need for a person who can play both roles.

Enter the BaaKwaa.

Let us see the typical responsibilities of a Business Analyst and QA Engineer in a traditional methodology, such as waterfall.

A Business Analyst:

• Understands the business domain
• Analyzes weaknesses and strengths and helps define new features
• Writes software requirements specifications for the development team

A Quality Analyst:

• Writes test cases
• Performs tests on software programs and finds defects
• Ensures the quality of the software

Here's a brief role description for a BaaKwaa in an agile team:

• Write the user story (thus capturing business requirements)
• Write the acceptance criteria (thus further expressing the requirements through examples)
• Write the acceptance criteria in a BDD/ATDD framework in the language of the framework (example: Fitnesses, Cucumber, StoryQ, etc)
• Verify that the implementation meets the acceptance criteria preferably through automated means.

I'm not suggesting that we are witnessing the demise of the specialist BA and QA. There is a role for the specialist and there always will be, just as we continue to have architects, DBA's and user interface specialists in agile teams. However, they will be required to drop their BA or QA hat quite often, and instead wear the BAQA hat.

Please welcome the BaaKwaa.

Agile: The Preacher and the Practitioner

In an Agile conference, you will find two types of attendees - the preachers and the practitioners. The preachers are the speakers, the trainers and the agile "experts". They believe implementing an agile methodology in a text book like fashion is the only way to do it. The practitioners are those who have started an agile process in their company, are struggling to make it work and are dealing with real organizational and people issues.They see value in the agile process but do not think it can be done in a textbook fashion in their organization.

Here is what, for example, some of the agile preachers believe:

• SCRUM-But is evil. Not implementing an aspect of SCRUM points to an impediment that must be fixed.
• You must have teams co-located.
• Autotmated testing (TDD), continuous integration, etc. is a must.
• The Product Owner is always available to answer the team's questions. 
• Team resources are fully dedicated to the sprint. 
• Deadlines can and should be stretched to acommodate quality.

Here is what, for example, some of the agile practitioners have experienced:

• SCRUM-But is a reality for organizations dealing with legacy products.
• Co-location is a luxury in today's era. Often, even in the same geographic location, some team members work from home.
• Automated testing, continuous integration is often not possible for legacy applications.
• The Product Owner (Product Manager in the real world) is often managing multiple projects. It is an illusion to assume the Product Owner is dedicated and available.
• Team resources - especially QA, DBA, Architects often work on multiple projects or agile teams concurrently.
• Deadlines are real. They are often final and products must meet them and make compromises in the process.

The Agile Preacher often comes off as a white collar intellectual mostly used to working in laboratories, where things are largely under control. The Agile Practitioner, comes off as a blue collar worker, just interested in getting the job done in the real world with real people and real challenges to face.

The truth, as usual, is in between. Agile Preachers must temper their language to factor reality. Agile Practitioners must try to change reality. And in this tension between the two groups is where we'll see real value being added to the Agile Process.

Agile Boston Open Space 2010

I attended Agile Boston Open Space 2010 (http://www.newtechusa.com/agileboston/events/AgileBostonOpen2010.asp) today. The event was at the Microsoft Building in Waltham, Boston. Of the many conferences that I have attended, I have no hesitation in saying this gave me the most value for money. Here's why:

1. Convenience: It was in my backyard - just a couple of miles from my workspot. It certainly helped that while the title had Boston in it, it wasn't in Boston. It was in Waltham (you can tell I don't like going to Boston).
2. Cost: Just $29. And that included breakfast and food. And yes - there was vegetarian food. It was just a wrap, but it was tasty. This is not a trivial matter. I'm a vegetarian and I have often found that some conferences that charge heavy fees don't pay much attention to the vegetarian fare. These people were thoughtful.
3. I got to hear Ken Schwaber for an hour.
4. I got to network with a number of smart people who were willing to teach, learn and share. I learn't about a number of misconceptions about Scrum. Just because it is highly adaptive doesn't mean that you shouldn't do some of the process that truly added value in waterfall. People didn't say that in so many words, but that was the gist of what I got from it. If it's valuable, keep it.
5. I learn't about "Open Space Technology" (http://www.openspaceworld.com/brief_history.htm) - a fabulous way to organize meetings very productively.

I think it was a day very well spent.

TDD is a Misnomer

We all know, at least those of us in the software community, that TDD stands for "Test Driven Development". That's a huge misnomer. Simply because TDD is much more than about tests. Yes - tests are a core part of TDD. But TDD is also about the following:

1. It's a way to capture behavior (think requirements)
2. It's a design tool (If it's easy to test, the resulting code will be elegant)
3. It captures high level documentation (think tools like agiledox)
4. It's a regression test suite.

The word "tests" in it leads to all kinds of confusion among TDD practitioners. What do I test? How do I test? What do I test first?

Happily, we now have Behavior Driven Development - which simply removes the confusion around TDD while taking it to a whole new level.

Yes - I'm beginning to like BDD a lot. It's a better TDD and more.