AgileIQ Blog

Acceptance-Test-Driven Development: Are We Flogging a Dead Horse?

Mon, 10 Jun 2013 16:19:00 GMT

Or: Functional Testing Practices I Do and Don’t Like and Why

Functional Testing Practices I don't like

I’m going to start with what I don’t like, as it will create more context for what I do like, and because it is nicer to end on a happy note. But first, let’s get the definitions out of the way.

What exactly is ATDD?

The first thing I don’t like about ATDD is the sheer amount of confusion in the industry about what the term means. Follow these links for examples of the confusion around definition:

In order to move past this hurdle and on with my argument, here is a definition of the term and some others related to it, so we have a common understanding.

Acceptance tests: otherwise known as customer tests and previously known as functional tests, these are tests that match/replace the acceptance criteria of a story. The concept has its roots in Extreme Programming (XP). The idea is that the customer will accept the story when all the acceptance tests pass. Or, put another way, a passing suite of acceptance tests constitutes part of the Definition of Done for a story, iteration, or sprint.

Because acceptance criteria are typically expressed at a high level of user functionality, Automated Acceptance Tests (AAT) are often written using GUI driving testing frameworks (e.g., Selenium). These tools are sometimes referred to as Acceptance Testing Tools/Frameworks.

The Agile community has long wanted acceptance tests to be written by the customer (hence the newer name of customer tests), ideally before work starts on the story. The acceptance tests are written before the code; this leads to the term Acceptance Test Driven Development (ATDD) or Automated Acceptance Test Driven Development (AATDD), because it follows the pattern of test before code as practiced by Test Driven Development (TDD). I will address TDD later.

If you have implemented Scrum as your Agile practice, read “product owner” in place of customer. You will find me switching between the two terms in this article.

Product owners didn’t buy into the vision

The reality of the above vision of acceptance testing is that most product owners were unable or unwilling to write such tests, particularly if they required using a scripting or programming language.

When the Agile community witnessed this reluctance, they thought that if product owners could create tests using familiar applications like Excel or Word, then the practice would become more palatable and widely accepted. This resulted in testing tools such as FitNesse. I’m going to step out on a limb and say that for the most part these tools didn’t work in the hoped-for manner. Even using this medium to write tests, product owners were still reluctant to produce testing artifacts and found the output of FitNesse confusing and of little value to them.

So the community went back to the drawing board and valiantly tried to another approach. Enter Behavior Driven Development (BDD). The BDD approach was to create a framework where the tests are written in plain English and saved as plain text documents. The thinking was that if we make it simpler, product owners and customers will want to write tests. Agilists hoped that if the customers could do this then the clever devs and their BDD frameworks would do all the other magic to turn these plain text documents into automated acceptance tests.

I have yet to see a product owner get excited about this breakthrough and throw her arms into the air declaring “Hallelujah! Finally I am in control of the quality of this project!” Nor have I seen a product owner thanking the Agile community for developing the tool that he has been waiting for all his life.

In short, I feel that Agilists are guilty of not understanding the product owners' needs and are telling them how they should be doing their job. This is akin to software companies with the view that the users are the problem and need to be educated – “if only the customers would get just how awesome this product is then they would use it the way that we designed it – the way they are supposed to use it. The users need all these awesome features we have created for them but they just don’t understand the concept.”

Product owners aren’t coders, they’re business people

Product owners have their role because they understand requirements, customers, business drivers, marketing, sales, and more. They are often business analysts and spend much of their time talking with customers, stakeholders, sales, marketing, and usability experts; visiting sites/customers; and making themselves available to the team to answer questions, providing scope and resolving any uncertainty that may arise in a story during an iteration. Thinking of acceptance criteria in a certain format or in a programming language is often incompatible with their skill set and interests. In my experience, this is why they are reluctant to write acceptance tests. They seem happy to create acceptance criteria when asked, but are often reluctant to do anything more than that.

Acceptance tests and especially BDD tests are hard to refactor

Acceptance tests tend to just grow in a corner of the codebase without being refactored. The acceptance test regression suite (the accumulated acceptance tests) gets added to each iteration and no thought (e.g. do we need to refactor these tests? Are they still relevant?) goes into the question of duplication and quality. Test Code is a first class citizen and needs refactoring. Acceptance tests often don’t lend themselves to being refactored, and I have yet to see a way to refactor plain text BDD tests.

Acceptance and BDD test suites are slow and this only gets worse over time

An acceptance test regression suite keeps getting bigger and bigger and slower and slower. You may find, when working on a story, that one small change can break a hundred or hundreds of these tests, forcing you to go back and edit each of these failing tests. More often, the entire suite is thrown out and the ATDD/BDD exercise is declared a failure.

When the running of an acceptance test regression suite starts taking an extended period of time, you lose the benefit of short feedback cycles. The likelihood of a dev team taking action on a failed build reduces in relation to the length of time the build takes, i.e., the longer the build, the less likely it is going to be maintained and acted upon when it fails. Without refactoring, any test suite will suffer from accretion and entropy, and eventually be abandoned – particularly if the suite starts to take longer and longer amounts of time to run.

Acceptance and BDD test suites are fragile and cost time to maintain

Acceptance tests are known for suffering from false positive test failures. Development teams are unlikely to take any action when the build fails when they are tired of expending vast amounts of time and energy trying to fix fragility. It is hard to ascertain if the failure was a bug in the code, a bug in the test, a change in the environment, or just the suite framework being flaky. Fixing bugs that are intermittent and hard to reproduce is notoriously difficult and time-consuming. When this happens repeatedly, the solution is often to comment out the test, remove the test, or abandon the entire suite.

ATDD focuses on the wrong part of the testing pyramid

Don’t get me wrong, I like integration, system, and end-to-end tests. I’m in favor of testing the entire pyramid (see the pyramid below). I’m not suggesting throwing the baby out with the bathwater when I criticize ATDD and BDD. An advanced development team should be able to get functional tests to run quickly and be stable and appropriate for the product. But too often new teams leap on ATDD as a best practice, and the testing pyramid is turned upside down as their primary focus moves to the top of the pyramid where ATDD lives. In the pyramid diagram you will notice that unit testing and Test Driven Development (TDD) should be the primary focus of the team and the foundation block of all testing. When a team is proficient at TDD with unit tests, they are more likely to create the appropriate level of testing at the higher levels of the pyramid. In my opinion, ATDD should not be undertaken by beginner (or SHU level) development teams.

ATDD is too often mistaken for TDD (Test-Driven Development)

“We do TDD here” is a comment I hear too often from teams that are not doing any unit testing but have focused their testing efforts on functional testing only and believe that this is what TDD is. Even if you are writing unit tests, that doesn’t mean you are doing TDD. Unless you are writing the unit tests at the same time as the code, you are not doing TDD.

ATDD can encourage big design up front instead of emergent design

While everything else in Agile follows the philosophies of just in time (JIT) and simple design, many of the assertions that arise from acceptance tests before code implementation are based on assumptions in functionality that turn out to be wrong once the code and design have emerged. This then requires you to have to rewrite the acceptance tests during the iteration. Having loose or vague requirements (as favored by Agile) means that the way you implement a story may be very different from the way that you thought it would be implemented before you started the story. The ability to develop the solution is embedded in Agile processes and is indeed one of Agile’s strengths. Because of this I’m going to claim that many acceptance tests go against Agile architecture and emergent design.

This mostly happens when your acceptance tests are driving a GUI. Now I am not opposed to designing a GUI up front, and indeed it is helpful for the developers to have a design or mock to work from when implementing the story. But often, it is only when you start implementing a design (coding) that you find all the flaws in the design and all the edge cases that the designer did not think of when creating the design. This results in the design and/or functionality changing, or emerging (part of emergent design) during an iteration. It is a waste of time and effort to have written tests against the GUI before the GUI is implemented.

ATDD is time consuming and not lean

The practice of ATDD can consume time in these areas:

Creating fixtures to drive BDD tests
Rewriting the tests after emergent design has changed the original design
Maintaining a fragile suite that suffers from false positives
The tests themselves are slow to run

This is not an insignificant amount of time and definitely not lean in nature.

BDD context switching

I prefer acceptance testing tools that sit on top of the same technology that you are using for unit testing, like JWebUnit which runs on JUnit. You can edit and run the tests all in the same IDE. BDD testing involves switching between IDEs and/or language technologies, and that feels unnecessarily disjointed to me.

When do you call the horse dead?

The industry has had long enough to try the concept of acceptance testing out on the community of product owners, and the uptake has proven poor. I call that a failure.

So how much longer are we going to flog this dead horse? Compare this to the uptake and acceptance of TDD as a practice. TDD has stuck and works. ATDD did not, and the Agile community at large seems to keep wanting to revive it by changing its shape and creating new frameworks and approaches instead of ditching it.

Testing Practices I Do Like

Writing good, clean, and readable tests

Your tests are a first class citizen and form part of the documentation (or specification) of your application. Learning to write good tests, wherever they are in the pyramid, is an art in itself and one that must be learned by every Agile developer and practiced by every Agile team. Bob Martin has a great chapter on Unit Testing in Clean Code: A Handbook of Agile Software Craftsmanship. The pattern of keeping test code clean applies to all types of automated tests.

Refactoring tests

All code, including test code, suffers from rot and needs to be kept fresh. Learn to refactor your tests. I highly recommend Gerard Meszaros’ book on this topic, xUnit Test Patterns: Refactoring Test Code.

Use the right tool for the right job. What Specification frameworks are good for

If your business has areas of functionality or business logic that have to meet compliance or legal requirements and be documented, then this can be a good use of a BDD or other specification testing tool. You can meet the compliance requirement around documentation and build a valuable test artifact at the same time. Win/win!

BDD test protocol

Given, When, Then is a nice way to think about your tests. It has become very popular among unit test frameworks as well. I like it. It is similar to the Arrange, Act, Assert pattern but it builds the pattern into the test protocol and thus improves the readability of tests.

Following the testing pyramid - Agile Testing

High performance teams I have worked with know how to use end-to-end and integration test frameworks effectively to ensure that they are writing quality code and are not breaking functionality as they go. They know when to write these tests and what to test. They know how to refactor these tests to avoid fragility and keep them fresh and relevant. They know how to avoid duplication in these tests, and how and when to implement configuration management. They take ownership of writing and maintaining these tests (as they do for the quality of the entire product in general). They know how and when to break these tests into suites to optimize build performance – for example, splitting out a smoke test suite that runs on every local build and a more complete regression suite that runs on a CI server after each check in. They know how to create suites of tests and how to schedule and chain builds – for example, running stress/performance testing and/or benchmarking every night. And not to be forgotten, the base of the testing pyramid is solid! That is to say, they have embraced TDD and have a high level of unit test code coverage.

This is what I call “Agile Testing,” and it refers to the entire pyramid. I have asked non-coding Agile consultant colleagues to use this term when talking about best practices for Agile teams instead of the (somewhat rhetorical) terms ATDD and TDD. The rule is if you can’t write it, don’t talk about it – instead use the term “Agile Testing.”

Agile Testing Pyramid

Healthy testing pyramid

Unhealthy inverted testing pyramid - when ATDD takes center stage

(Source: Flipping the Automated Testing Triangle: the Upshot)

(Horse portrait by Yago Partal)

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/94001/Acceptance-Test-Driven-Development-Are-We-Flogging-a-Dead-Horse

Mending Walls With Team Friends

Wed, 05 Jun 2013 07:46:00 GMT

by Michael Tardiff

Scrum is focused on teams. But who's on the team? And how can others help?

Not too long ago, a manager told me, "It seems like you're saying that Scrum separates me from my team. That doesn't feel right, because I've worked hard to create an open atmosphere here." He had a point: the language we often use when talking about Scrum teams includes "protecting" the team and focusing on the people who have "hands on the keyboard." We think we need to separate the Scrum team from their partners in the organization.

Before I built a wall I'd ask to know What I was walling in or walling out,
And to whom I was like to give offence.
– Robert Frost, "Mending Wall"

That conversation reminded me of a time, years ago, when I was working with a team whose managers had asked me to help them learn how to deliver using Scrum. These folks worked in what some technology professionals might see as an extremely stable company; many people had been at the company for double-digit numbers of years. They worked together, celebrated together, knew each other's families and kids. They knew a lot about being together before I ever came into their lives.

When it came time to form the Scrum team – choosing who'd work on which team, who would serve as ScrumMaster, and so on – we got a bit stuck. "I think I should definitely be on the team," said Richard, who was the manager of most of the developers and testers who would be working together. "I need to see what the team is doing." Others piped up, remembering what we'd learned about cross-functional delivery teams, and offered that Richard didn't have a delivery role; he was a manager.

The brand-new ScrumMaster, Amy, suddenly brightened. "Richard," she said, “what if you were a 'team friend'? We're going to have lots of challenges as we learn to work using this Scrum thing, and we'll need all the help we can get. And friends are important: they care about you, they'll listen, offer advice...they'll pitch in and help you out when you're in a tough spot. Sometimes, they'll even lend you money!"

Amy had captured everything I'd wanted to say about supportive work environments and empowered teams. Our team was going to need friends to survive our learning and adapting times ahead. And so Amy made a poster labeled "Our Team Friends" and invited Richard to come over and sign in as our first friend.

When the poster went up on the team's wall later that week, it quickly attracted the attention of others whose work brought them into frequent contact with our team. "Can I be your team friend too?" they'd ask, in all earnestness. Amy would explain what our expectations were from friends, and to our surprise, one by one they happily signed their names.

Here's the best part: We soon discovered that one of the team members had to be gone for two entire sprints, and the team felt shorthanded without him. Richard heard our concerns, and said, "Could I help? Could you use an extra hand?" The team was surprised at his offer, but quickly accepted it. Richard, like a true friend, backed us up wholeheartedly – he temporarily moved out of his office and onto a table in the team room, and there paired with team members to deliver software, complete stories, and accomplish our iteration goal. Reflecting on Richard's contributions at our retrospective a month later, we realized that we couldn't have done it without him. And the team felt that they had a real commitment from management to support them through this time of change.

I wished that I'd remembered Amy's idea when I was working with that recent team and its involved, supportive manager. But it's not too late for them, nor for your team. Consider inviting the support, understanding, help, and trust of those "outside" your delivery team. Make more friends, and try to keep them. And don't forget to invite them to the post-sprint celebration at the pub!

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/94227/Mending-Walls-With-Team-Friends

The Definition of Ready in Agile Development

Fri, 24 May 2013 16:13:00 GMT

by David Wylie

Our development teams have an insatiable need for work to do. It is very common for them to deplete the Product Backlog of items that are ready to be taken into a sprint. It is also common that the Product Owner (PO) and stakeholders have lots of partially defined work in the backlog. This caused frustration because the team can’t bring in work, yet there is plenty to do.

To help with this, our teams work with the PO to agree on what defines a “ready” state of a backlog item. This will vary by project, but below are some elements to seed the discussion:

Story defined and written
Story traceable to source document (where appropriate)
Acceptance criteria defined
Dependencies identified
Size estimated by delivery team
User experience included (where appropriate)
Performance criteria identified (where appropriate)
Person who will accept the user story is identified
Team has a good idea about how to demo the user story

Some other really smart Agile thinkers have been talking about this for a while:

The Definition of Ready (Roman Pichler)
Definition of Ready (Ken Power)

We suggest that the Definition of Ready be published to the PO and all stakeholders we can identify. It also highlights the importance of the ScrumMaster’s opportunity to support the team by working with the PO to ensure there is at least a sprint’s worth of data ready to go. Along with a team Working Agreement and Definition of Done, consider adding the Definition of Ready to your Scrum team's toolset.

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/94102/The-Definition-of-Ready-in-Agile-Development

Why Are You Not a Software Engineer?

Thu, 16 May 2013 16:26:00 GMT

by David Wylie

Are you a rock star developer? A prodigious code creator, widely read, developer of new frameworks, familiar with many languages? Then you may not need this advice because you are already productive (unless you have an unusual level of humility and desire to improve).

For the rest of us normal folks, there are things we can do better.

The practices that lead to good software are well known:

Work frequently and closely with requirements providers
Write automated tests
Check in small changes and run the tests
Demonstrate new code and release regularly
Pair program

Extreme Programming has been around for a long time. BUT MOST DEVELOPERS ARE NOT FOLLOWING THESE AGILE PRACTICES! Sorry, this is bothering me.

If you are not a rock star and don’t follow these practices, you can be better. I bet your code takes longer, has more bugs, and does not meet business expectations as well as it could.

Perhaps it is a marketing failure. The name Extreme, and the initials XP, have connotations that must repel some folks. Current people in management grew up in a time before XP, so they might not like the “communist” components of open work spaces and collective code ownership. Many people became developers because they either don’t want to or suck at dealing with other people, developers or business folks. Those people are not having the positive impact that is within their potential.

Engineers have known good practices that they follow. In fact, if they don’t follow good practices, they can lose credentials and be held liable for failures.

We should hold ourselves to similar standards. We know the practices that work, and it is not a matter of opinion.

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/93680/Why-Are-You-Not-a-Software-Engineer

Distributed versus Scattered Teams

Fri, 10 May 2013 16:25:00 GMT

by David Wylie

I think we need to refine how we define teams and team members when they are geographically dispersed. The issue is how best to implement technical practices, work distribution, and communication among team members in different locations. A key Agile principle recognizes that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversations.” How does this apply in a world of distributed teams?

There are many successful implementations of projects where sub-teams are geographically distributed. What they have in common is that the sub-teams have 2-9 people who can work together in the same location. Successful examples (SolutionsIQ, Sutherland, Yap) show that teams/sub-teams in different time zones can deliver regularly with high quality. In most of the projects where teams have participated in remote pairing, the remote team has had two or more people in that location. If you have this situation, these groups should ideally be feature teams, where the group can deliver a complete feature with minimal integration dependencies.

Though remote pairing has been done successfully several times at SolutionsIQ, some of our strongest developers had a challenge with remote pairing. It should be pointed out that on the highest-performing distributed teams, team members start out working together in the same location for a period of time at the start of the project. This allows relationships to develop and norms of practices and behaviors to be established.

We continue to see challenges with scattered teams where individuals are geographically isolated. New technologies like desktop sharing and video (WebEx, Skype, Vuze, VNC, Join.me) help, but our experience shows significant challenges. Chief among them is that having people work from home, a classic pattern, leads to individuals delivering and maintaining expertise. This is contrasted with the team delivering, and sharing of knowledge and responsibility within the team. Individuals can still follow good technical practices like TDD and CI, but positive peer pressure is reduced. Code review and knowledge sharing has to be dealt with separately if pairing does not happen. Team estimation and team velocity are very difficult, and that leads to limitations on release planning. Demonstrations by remote team members are harder but possible. Product owners can ask questions and seek clarifications via conference call, but conference calls can easily become individual conversations. Most of the scattered teams I have encountered do not meet together on regular basis.

If you have remote individuals, then they need to be managed as individuals, not as a team. Wishing for team behaviors will lead to disappointment.

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/93677/Distributed-versus-Scattered-Teams

Is the Product Owner on the Scrum Team?

Fri, 03 May 2013 16:40:00 GMT

by David Wylie

Some people that are new to Scrum believe that the product owner has to be kept at arm’s length. Originally, Scrum books taught that the PO and the development team were separate. I’ve even heard people state that the PO is a chicken, and not as committed as the pigs on the development team. However, according to the latest Scrum Guide, the Scrum team includes the development team, ScrumMaster, and product owner.

Is the product owner part of the team or isolated? Agile principles say that the team should work with business people daily, and the best way to convey information is face-to-face; we also teach that teams ideally are colocated. So in an ideal state, the PO does colocate with the team -- if not, he or she still needs to be available to the team on a daily basis, either in person or via other communication methods.

It always depends on the people involved, but many teams are including the PO in sprint retrospectives. If there is a lack of trust between the development team and the PO, then the ScrumMaster has work to do. Everyone should be working together to deliver value, and the best product owners are on the team.

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/93516/Is-the-Product-Owner-on-the-Scrum-Team

Agile Values and Organizational Transformation

Fri, 19 Apr 2013 17:59:00 GMT

by Dan Williams

The Agile Manifesto was developed in February 2001 by seventeen people who met to find commonalities between several ‘lightweight’ methods that emerged in the 1990s. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming along with many others were able to agree on a core set of values.[1]

The values expressed in the Manifesto center on people and their interactions within the limiting context of the work environment. This does not mean that the values cannot be applied in other contexts such as the home or school, but it does mean that when speaking of Agile values, frameworks, and tools, we are generally speaking of work environments.

Agile is moving from the software industry, where it got its start, to major corporations providing all manner of goods and services. This shift is partly being fueled by articles in media such as the Wall Street Journal and CIO Journal.[2] Agile is the next big thing (NBT) and is touted as providing that silver bullet of delivering goods and services at the ‘faster, better, cheaper’ pace which seems to be the holy grail of business.

The crux of this article is that Agile is not a process or set of tools to accomplish the goals of business when those goals are limited to mere profit; it is rather a set of values that move us from primarily valuing the work product to valuing the work producer, the person. This may or may not produce improved profit margins. What has been demonstrated is that it does in many cases produce higher quality goods, happier, more fulfilled people producing those goods, and a better business context within which to work.

It is important to understand the fundamental shift in value perspective that Agile recommends to businesses. Process frameworks like Scrum, Extreme Programing and Crystal have been demonstrated to be successful as the Agile values which they promote are understood and incorporated into the business ethos.[3]

If the business attempts to apply one or more of the Agile process frameworks without understanding the need to incorporate the Agile values, the desired organizational change with the anticipated benefits of ‘faster, better, cheaper’ will tend to be minimal. This is due to the dependence of the processes on the values. How can we help businesses with this significant paradigm shift in their thinking? The following suggestions help smooth the way for businesses to move toward incorporating Agile values and processes into their environment:

Involve all levels of the business, including top level ‘C’ executives. Their sponsorship and support will be important.
Don’t neglect mid-level management as their support is vital to the success of the transformation.
Answer the question, “Why move to Agile?” This is important, as the reasons for attempting such a fundamental change should be well understood from both a quantitative as well as qualitative standpoint.
Understand the current business culture. Change is hard and there will be champions as well as potential saboteurs of the changes to come.
Spend time on the organizational structure to understand how it helps or hinders the move to Agile.
Create a roadmap with the explicit understanding that it will change over time.
Don’t attempt to change everything. Pick an area where a win will be evident and beneficial.

More could and should be said, but this is a short blog article and not an essay. I look forward to continuing this discussion and invite your comments.

[1] Agile Manifesto

[2] WSJ, CIO Journal

[3] Rally Software's Measuring Agile Success

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/92564/Agile-Values-and-Organizational-Transformation

Agile at PMI

Fri, 12 Apr 2013 18:13:00 GMT

by Dan Williams

Last night I attended the Seattle Project Management Institute (PMI) monthly dinner with my wife. As I am a PMP in good standing and hold the new Agile Certified Practitioner (ACP) certification from PMI, I was very interested in the topic and the speakers presenting. The topic for the evening was Creating an Agile Culture. The speakers were Joseph Flahiff, President of Whitewater Projects, Inc.; Ann Konkler, CSM and Agile Coach from Rally Software; and Jim Grams, CTO from Online Shoes.

The speakers shared their perspective of the major cultural shift experienced by companies attempting to implement Agile values and processes. Joseph spoke from the consultant’s viewpoint; Ann spoke as a practitioner and tools provider; and Jim spoke as a manager involved in an Agile transformation effort at his company. All of the speakers were united in their perspectives of the cultural impact of implementing Agile in their businesses.

Joseph defined the culture of a company as all of those factors that provide the context within which people do their daily work. For example, is work given or taken? And what are expectations around work hours, quality standards, communication, reporting, metrics, prioritizing work and respecting sprint boundaries? Joseph emphasized that Agile values are the most impactful part of introducing Agile to a company. In Joseph’s experience, the Agile Manifesto, with its emphasis on respect, collaboration, and value, caused a major cultural shift.

Ann continued the discussion about culture by emphasizing the turmoil that can result during the transition from waterfall techniques to Agile. Fear of change, new methods, higher degrees of communication than before the transition, and new job titles all contribute to the impact that Agile can have on a company.

Jim closed the discussion with examples from his company, which began Agile transformation last year. A key point was that he acts as a shield between upper management and the development team. Management was used to micromanaging and randomizing the team almost on a whim. By enforcing the concept of taking prioritized work and respecting sprint boundaries, rework at Jim’s company has dropped and output has increased 95%. Jim stressed keeping good metrics around improvement in order to show management why Agile techniques are superior.

PMI is actively endorsing Agile as a significant project management technique. The ACP certification places Agile on par with traditional PMP practice; this certification provides a welcome tool that SolutionsIQ can use to help companies transition smoothly to Agile.

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/92819/Agile-at-PMI

The Problem with Velocity

Fri, 05 Apr 2013 19:58:00 GMT

by Ron Quartel

There is a smell in Agile around velocity (and estimation) that has not been resolved yet. So what is wrong with velocity? Below are the myriad questions that I get asked whenever teaching velocity that indicate to me that the concept is not particularly simple and that there is a smell (to use a developer phrase).

How do we account for capacity changes from sprint to sprint?
What do we do with capacity when the team is particularly cross-functional in nature and has developers and non-developers on it (e.g. testers, business analysts, UI, tech writers)?
When the backlog is being supported by multiple teams, do we have them aligned around the same sizing, and if so, how?
Do we measure personal velocity (i.e. by team member)?
Do UI points differ from testing points, tech writing points, etc.?
Do we track actual and estimated velocity?
How do we track/account for stories that spill over with regards to velocity, and what size the stories end up being?
Do we get credit for part of the story that was complete (when we don’t hit commitment)?
Do we burn up points and then stop work on the story when we have delivered that many points of value?
Do we put points on spikes and/or research tasks?
Do we put points on bugs?
Do we put points on non-dev activities that are in the sprint but required to get to completion?
Are points just complexity, or is there little complexity and a lot of repetition or time?
If we change team members do we need to recalibrate the points?
If we take velocity as an average of the sprints, how do we account for different capacities in the sprints?
Is velocity a rolling average or the average from day one forward?
If rolling, how many sprints should we use?
Do we need to reset the velocity when the team changes?
Can we have an exchange rate on our points to another team’s points?
Points aren't real, so why should we use them?
If we do extra work in the sprint that wasn't planned for, do we get credit for it?
Should the goal be to increase velocity each sprint?
If multiple teams are working off the same backlog, do they have to be using the same point values?

I have answers for all these questions and I am not going to go into them here. My point is that the concept of velocity is not as simple as it seems on the surface, and in fact has some serious flaws.

So what is the solution?

If velocity is not a problem for your team because you have found something that works, then yay! Stay with it. I have seen it work well and not so well. It seemed to work best in teams that were comprised solely of developers that were pair programming (e.g. XP teams).

Switching to Kanban will resolve many of the issues, but only if Kanban fits your release process. Unless you are making use of inspect and adapt at the end of an iteration (which is what iterative development gives you) then you may as well ditch iterative development and go with a flow system like Kanban. Or, if you release to a heartbeat cycle and whatever is done by the next release point gets in, Kanban might be a better fit also. Kanban has a different approach to throughput than velocity, that does not raise all the questions above – hence the recommendation, but only if the process fits.

Otherwise, watch this space, or please let me know if you have any ideas or have seen something that works to resolve this aspect of iterative development.

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/92650/The-Problem-with-Velocity

Without Support You Will Fall, Part II

Fri, 29 Mar 2013 22:28:00 GMT

by Steven M. Smith

In my last post, I examined the lessons teams can learn from the historical examples of British Prime Minister Margaret Thatcher and FEMA Deputy Director Michael Brown. In this post I will continue to analyze the patterns resulting from the interaction of three variables: ability, demand, and support.

The Scuttled Pattern (Carly Fiorina, 1999-2005)

Carleton (Carly) Fiorina was CEO of Hewlett-Packard (HP) from 1999-2005. Her command ship was scuttled in 2005 when she lost the support of HP’s board.

Prior to HP, Fiorina was the executive vice president at AT&T responsible for spin off and initial public offering of Lucent Technologies. She joined Lucent’s executive management team where she was chairman of a joint venture and later a group president for its global service provider business. I think it’s fair to say she was a person of proven ability.

When she became CEO of HP, the demands on the business were considerable. HP had been unsuccessful at exploiting the Internet; it had lost ground to perennial rivals IBM and Sun Microsystems; and Compaq and Dell Systems were growing, thus eroding HP’s share of the PC market.

In 2001, Fiorina’s plan was to break up HP and merge the parts she kept with PC maker Compaq. HP board member Walter Hewlett (the son of the “H” in HP) publicly objected to the merger, describing it as an act of desperation. David Packard (son of the “P” in HP) publicly said that the merger plans were a cruel departure from the values and corporate culture of HP’s founders.

Describing the situation, Fiorina said, “Most of the media… is positioning the merger with Compaq and the recent actions by Walter Hewlett and David Packard as a fight between the past and the future.”

Fiorina won the battle for the future, but it was a Pyrrhic victory. The win had cost her support. She continued to win battles, but lose supporters. Each lost supporter drilled another hole in the hull of her command ship. Eventually the bilge pumps couldn’t keep up and the ship sank.

What lessons can teams learn from Carly Fiorina’s HP experience? Support is precious. Find strategies that supporters believe are right even if they aren’t your favorites. Constant fighting with supporters, especially public brawls, will eventually scuttle your ship.

The Bored Pattern (Winston Churchill, 1945-1949)

After successfully leading Britain through World War II, Winston Churchill’s Conservative Party lost the election and he was forced to step down as Prime Minister. It crushed him. Without popular support and the high-demands of being Prime Minister, he grew frustrated and bored.

Never a ray of sunshine, his sarcasm and black moods increased. Although he remained in Parliament, he brooded over the atomic bomb, the Soviet menace, and creating “a United States of Europe.” But he had enormous amounts of free time compared to the war years as Prime Minister.

He channeled his unused ability into writing and painting. He was excellent at both. He was awarded the Nobel Prize in Literature and his impressionist paintings have been exhibited around the world and continue to attract attention. On painting, he said, “Armed with a paint-box, one cannot be bored, one cannot be left at a loose end, one cannot ‘have several days on one’s hands.’”

But things change. Uncertainty about foreign threats created demands that matched his ability. Support began building. In 1951, his Conservative Party won a majority and Churchill returned to being Prime Minister.

What lessons can teams learn from Winston Churchill’s post-World War II experiences? Don’t waste your talent and skill. Focus your unused ability on activities that provide you with a sense of accomplishment. Keep supporters aware of your abilities. Things will change.

The Energized Pattern (Mahatma Gandhi, 1915-1945)

Mohandas (Mahatma) Gandhi energized and led the Indian subcontinent out of British domination. I consider him the greatest change agent of the Twentieth Century.

After ten years of leading the civil rights movement in South Africa, Gandhi returned to India in 1915. He faced daunting demands. British dominance had become the status quo for two generations of people born on the Indian subcontinent. And Britain was determined to maintain its dominance by all means necessary.

Using methods of nonviolent resistance, a philosophy of fearlessness, and his personal example, Gandhi’s Indian independence movement gained more supporters. And with more support came new demands, which called for him as leader to develop new skills. One generation after his return, the movement won its independence.

I question whether anyone would have said in 1915 that Gandhi had the ability to successfully lead a movement of this size and complexity. But I believe he convinced himself that he could and in the process energized himself and his followers to develop the necessary skills.

Gandhi said the following about acquiring ability: “Men often become what they believe themselves to be. If I believe I cannot do something, it makes me incapable of doing it. But when I believe I can, then I acquire the ability to do it even if I didn’t have it in the beginning.”

What lessons can teams learn from Mahatma Gandhi’s struggle for Indian independence? Have faith. Believe in yourself. Set an example. Use the difference between your perceived skills and your desired skills as energy for bridging that gap.

What’s the difference between the cases of Thatcher and Gandhi versus Brown, Fiorini and Churchill? Support. If your team is failing to nurture support, you will fall.

What’s the difference between the cases of Thatcher and Gandhi? Thatcher had an existing (governmental) structure to use to implement her policies. Gandhi had to create a new structure. Thatcher was clearly skillful and energized, but Gandhi’s movement seems to me to have required much more energy.

Did Brown fail because he didn’t believe in himself like Gandhi did? No, I suspect Brown did believe in himself. He may, however, have suffered from hubris. With better support, he may have been able overcome the demands that swamped him. But he apparently didn’t foster that support.

What does the case of Churchill tell us? An active life is bound to have setbacks. The period described wasn’t Churchill’s first setback. With support, our abilities can be applied to larger demands.

What would you add to this analysis?

View this original blog post here: http://www.solutionsiq.com/resources/agileiq-blog/bid/92320/Without-Support-You-Will-Fall-Part-II