Posts Tagged “adopting agile”

I’ve always been puzzled why Kanban attracts so much attention in the agile community. At its essence Kanban is workqueue on a wall. Why would any team, delivering within a healthy iterative cadence, switch to a method that does nothing to support a sustainable pace for team members nor provide real delivery planning and predictability to the business?

During a conversation with Rebecca Porterfield, of Solstice Consulting, I realized that I have been looking at Kanban from the wrong perspective. Rebecca has recently rolled out Kanban with a client that had no existing process. The client’s team fell in love with Kanban instantly. It was a welcome relief to the interrupt-driven, everything-is-a-priority world to which the client was accustomed.

This conversation made me realize that Kanban is ideal for teams that have yet to take the agile plunge. Kanban is a quick hit of simple rules that fills a process void. It appeals especially to those who dwell in process-free (or chaotic) environments.

Kanban can be mundane and underpowered for the experienced agilist. It doesn’t provide me with much assistance on my current 30 person, multiple-system, heavy-process-mandated, regulation-driven, do-or-die project.

For the uninitiated, however, Kanban is a grand welcome into the agile community. Many teams (although not all) can invest a little effort in Kanban and reap significant reward. Then the teams get comfortable and even excited about adopting additional agile practices. This makes Kanban the ideal gateway drug to agile.

Comments 2 Comments »

Andrew Wicklander over at Ideal Project Group has a great post on the answer “not yes.”  I hear this answer an awful lot when taking teams agile (or more agile).

“Not yes” is the answer you hear when you request permission to do something that’s not well understood by the requestee (such as initiate a daily stand).

The “not yes” answer means the requestee has no interest in saying “no” but doesn’t want the accountability of saying “yes”.

The “not yes” answer gives the requester the opportunity to try, succeed and reap the rewards of that success. But failure, and the costs of it, fall directly on the requester.

Welcome to the world of agile adoption. We thrive and starve on “not yes” answers. More often than not we thrive, which is why agile has achieved its current level of popularity.

But failure can be a major setback, because agile takes all the blame.

This “not yes” answer may help to explain why agile development can be such a polarizing topic. Across a multitude of organizations, the “not yes” answer has heaped the responsibility both for great success and great failure on agile. Regardless of whether this is accurate or fair, it’s no wonder there’s so much passion and experience on both sides of the agile debate.

Comments No Comments »

The business side of the house can be difficult at times. They can challenge our estimates, claim that work is not half as difficult as we make it out to be, drop last minute delivery requests in the middle of our development cycle, and even (in occasional fits of complete frustration) threaten to offshore the lot of us.

So, what’s a lowly, victimized development department to do?

Turn to Scrum, of course. And play defense. Specifically:

  • Recruit ScrumMasters to protect the teams.
  • When the new ScrumMasters wants to discuss what’s right for the company, stress that the ScrumMasters were hired to protect the teams.
  • Grab a hapless business person, hand him a Black Book, crown him product owner, and tell him his number one priority is to live PivotalTracker.
  • Be specifically clear that the Product Owner’s number two priority is to communicate every user need in the “as a … I want … so that” story template.
  • Threaten to take the teams on strike until there are 100 storied story points prioritized in the backlog.
  • Go flash mad the fifth time someone asks “what’s a story point worth?”
  • Remind business people that chickens are not allowed to speak at daily meetings.
  • Deflect complication and nuance by declaring big business ideas as too epic in nature to consider for development.
  • Threaten to abend the sprint every time the business wants to change something.
  • Demand that the ScrumMasters protect the teams by ensuring they are capped at forty-hour work weeks. Ignore the fifty-plus-hour work weeks that are saddled upon the ScrumMasters. Scoff at the difficult working conditions of the business users.
  • Finally, don’t forget to whine vociferously that the business doesn’t get Scrum.

You could call this Scrum. I wouldn’t. I’d call it an anti-practice.

Whatever you do, please don’t call it agile.

Comments 1 Comment »

Scott Ambler started a minor brouhaha a couple weeks back when he rolled out his first draft of an Agile Process Maturity Model (APMM). I’m not stepping in to evaluate the proposal or the rebuttals because I believe that level of the discussion largely misses the point.

I’d prefer to rebut the whole conversation by reiterating the agile maturity model that I proposed in my book:

  1. The team has decided to start implementing agile development.
  2. The team has successfully implemented its first agile practice and has posted a copy of the Agile Manifesto in inch-high letters on a common wall near the team’s location.
  3. The team has adopted a second practice while collecting metrics and holding review meetings to measure its level of agility.
  4. The team is regularly adopting additional agile practices and actively monitoring its level of agility.
  5. The team has not checked its level of agility for months and is altogether focused on adopting and adapting any practice that will result in better communication, higher quality code, and a system that most accurately meets the needs of the business.

My point? Maturity models are good for selling something, They’re not nearly so useful when your focus is (1) maintaining a healthy team and (2) delivering valuable software. That’s because maturity models simply cannot account for the myriad environmental factors, technical challenges and orgainzational obstacles that teams face. The team that focuses on the characteristics that most directly drive its situation will win out – every time – over a team that evaluates and corrects itself using a borrowed yardstick built from industry standards.

Comments No Comments »

I’ve spent some time over the last week devising the simplest agile process I could come up with. Why? Because sometimes it makes sense to strip a process down to its absolute bare essentials and to build it back up again. This way we challenge our assumptions about what really needs to be in the process. We identify false safety nets, white elephants and non-obvious impediments. More generally, we can locate and eliminate the waste in our process.

So, what goes into the most simple of agile processes? To be both agile and effective I decided that the process had to be iterative, it had to encourage communication, it had to focus on delivery, and it had to be drawn entirely from techniques that I have seen work in practice on real teams.

So, without further ado:

Pretty simple, huh? A lot of this should be self-explanatory, but I’ll dive into the detail in my next post.

Comments No Comments »

In my last post I mentioned the Iteration Zero technique in passing. I’m going to tackle it head-on today.

Agile teams strive to deliver functionality that can be touched or even used by the customer at the end of the first iteration. Sometimes, however, it does make sense for the team to focus on building its foundation before delivering functionality. This may be the case for larger applications, for teams new to agile development, or for projects where the the features are still extremely fuzzy. These are perfect opportunities to execute an iteration zero.

Read the rest of this entry »

Comments 9 Comments »