Change J-Curve Discussion on the iScrum forum

August 3, 2009 at 4:59 pm · Filed under Uncategorized

In the last few weeks we (Agilesparks) have been trying to liven up the israeli scrum forum – iScrum.
This is a forum dedicated to practitioners of Agile/Scrum in Israel. There are some interesting discussions and ideas and its also a place to monitor for events in the israeli Agile/Scrum community (e.g. user groups, ask the expert sessions, etc.)

One of the questions raised was the issue of agile adoption curve. There are several interesting opinions, and I’ve been thinking a bit about this subject, see two of my comments:

ince indeed it is a journey, a critical question is what is the break even point on this project or in other words how long to roi.

The costs are investment in Learning, training, coaching as well as organizational time, attention and productivity loss due to learning curve and transition difficulties ( see the j-curve mentioned in the material Inbar quoted )

depending on the specific variables of the transition the time will vary but it will be more in the months time frame to years timeframe I think.

Note that at that point it’s important to continue to drive to more and more agility to get even higher benefits

and

Another reference to the change curve is in the Virgina Satir Change model also see .

An important point to take from this model regarding change and agile transitions specifically, is that the level of resistance/chaos that causes the productivity dip and risks to the transition, is a function of readiness and preparation.
An organization can minimize the time/impact of the dip by improving preparation. Improving preparation is possible if you assess your readiness for this change and focus on improving readiness before going into the change. While this sounds a bit un-agile, it seems like there is empirical research around this that shows that at least some of this preparation brings better results.

I’ve also been thinking about the implications of exactly how you do your agile transition (or any similar change for that matter) on the change curve. Some of my questions:
* Is it better to dive in across the board, or do it in vertical slices of the organization? In other words, is it better to stagger the productivity dip, or to have one big dip and get it over with? My instinct is to stagger the dip, with the added value that after one slice (department) has gone thru the dip, the organization has better strength/stamina to go thru another dip because it knows what waits on the other side, and its also more prepared at the organizational level to support the change. In addition the risk of a big organization going into such a dip, with the various departments feeding off each other’s dip, and the supporting functions trying to support everything and remove impediments everywhere at once, is a scary notion (speaking from experience…)
* Is it better to implement a change via a big bang methodology (e.g. Scrum) or a pattern/practice at a time? Here, while I think the dip will indeed be shallower for each practice, in most cases you’ll want to move fast to utilize the “driving force” of an enterprise-level change. It is important to note that after you DO the big change, it might be best to continue with one practice/pattern at a time, in a Kaizen/Continuous Improvement spirit. Note that the Lean/Toyota style talks about doing even the initial change in a flow mode rather than a large batch mode. Sounds agile to me ;-)

Together with a few colleagues we were looking at the effects of this curve on a big enterprise transition we are involved in, and trying to learn from it. I’m sure some more thoughts will come up…

Join us in the discussion!

Leave a Comment

Kanban/Scrumban at the Israeli Scrum user group 2009

July 16, 2009 at 10:45 pm · Filed under kanban

Yesterday was the Israeli Scrum User Group for 2009. While we have monthly gatherings, usually for an afternoon or so, we try to have at least one full day gathering a year. The gatherings are organized by Agilesparks – we are trying to push the Agile/Scrum community forward as much as possible – both because we believe in the collaboration and value add that this community/tribe provides, as well as because the stronger we are as a community, the further Agile will go in Israel, which is good for everyone working in the Agile space.

We had very interesting speakers from all over the israeli community, including some of our partners and friends, topped by a humbling appearance by the one and only Dr. Alistair Cockburn who gave a keynote and a couple of sessions. I still need to gather my thoughts and notes as there were several ideas I took home with me, both from sessions as well as lobby discussions and questions from my session.

One concept that struck home was Feature Thinning which Alistair presented as a way to have the minimum (thinnest) implementation possible, relevant especially in the tale end of projects, when under schedule pressure. This is especially useful when under Fixed Contracts, where you need to have that “checkmark” that a feature exists, and having some minimal implementation is better than paying a penalty for having nothing.

As the other coaches in Agilesparks know, I have somewhat of a Kanban fever these days. I implemented a Kanban flavored Scrum over in Sanrad when I was VP R&D there, and I think it was a neat solution for our situation. My presentation, inspired by ideas from David Anderson, Corey Ladas and Karl Scotland, was an introduction to the subject, and covered the Why we might want to look at Kanban, What is it, how it can Complement Scrum, and what can we do with it.

One of the key places I see Kanban providing some much needed answers is what happens upstream to an Enterprise-scale Scrum development cycle. In one of our clients, we see a lot of mess around the backlog, requirements elaboration, having just enough design/architecture ready, and all in all being READY-READY for the sprints. We are working on a workflow that will include Kanban that will try to address this issue. I’m very much a workflow kind of guy, and had a lot of fun playing with workflows in Issue Trackers (mainly JIRA) in the past. I see great promise in the visibility and WIP control that Kanban will provide in this area.

I also think teams can get a lot of value from visualizing the workflow and thinking in WIP terms inside their Scrum framework. This will lead to a process of addressing problems in the short term and identifying and removing systemic constraints in the long term, assuming retrospectives are held effectively.

One of the key questions, which was also raised by one of the other speakers – Guy Nirpaz, is whether it is wise to use Kanban as a starting point on the way to agility. Kanban is clearly a less prescriptive methodology, and can be abused quite easily to become a phased/waterfall process, if the strive towards small MMFs, fast cycle times and SLA is not there.

OTOH the Kanban approach seems to have some advantages compared to Scrum – transition can be smoother, and agility/leanness can grow from the needs of the workflow and metrics, not from thin air. This can make it easier and clearer to some folk, and since an Agile Transition is a tough change, anything that makes the process itself smoother is quite important. I’m looking for the opportunity to try this approach and see.

For now, I think it is safe to say that if you are considering a Kanban-based transition, you should seek some professional help to help ensure you are going to the right direction, and your guide/coach is keeping you honest. Same is still true for a Scrum-based transition IMHO…

In the meantime, take a look at my presentation and tell me what you think…

FYI it has been featured on the slideshare homepage – the editorial staff liked it for some reason or the other ;-)

Leave a Comment

July 6, 2009 at 9:47 pm · Filed under Uncategorized ·Tagged , , ,

Lately I’ve been trying to understand how best to represent Known Unknowns (KU) stories/tasks in the BDC. I’m talking about things like Support cases from customers – things not related to stories from the backlog essentially, that you know you will need to address.

Its the kind of stuff that “is not supposed to happen” as part of the sprint, but we’re in the real world, and in the real world, it happens.

I’m familiar with two major ways to account for those:

  • One is to remove them from the capacity. This removes it from visibility, OTOH it makes for a pure burndown/capacity/velocity calculation/tracking
  • The other is to create stories for those “buckets”. This way you can track them, have better visibility.

Assuming an organization is interested in tracking and measuring this part of the work, the team needs to integrate this into their burndown chart, velocity, etc.

The issue is that those tasks are sort of a “buffer for rainy day”, so the remaining effort on them as the sprint goes by is not necessarily related to actual invested effort compared to the whole bucket, but rather to time left where the events might happen.

Think support cases from customers – assuming you have a 30 day sprint. you planned on 20 days for the sprint based on yesterday’s weather. after 15 days, assuming you spent 5 days on this already, what should be the remaining effort for the BDC?
Naively, 20-5=15 days. But realistically, the statistics are that after half of the sprint, if your yesterday’s weather is to be counted on, 20/2=10.

Is anyone aware of any tools that manage these kinds of KU effectively without requiring the team/SM to manually update the remaining effort?

Together with some other coaches, we raised the option of drawing the planned work as an internal burndown line BELOW the total burndown. Another alternative was to show a burnup of this kind of work separately, so the team has visibility.

The idea is to make sure the team knows whether they got lucky and had more capacity left for their planned work, so should be more aggressive than their original plans, or the other way around. Without this kind of visibility, a critical aspect of the burndown chart is lost – teams don’t trust it, there is too much fog to see clearly where they SHOULD be so they don’t hold themselves accountable to where they ACTUALLY are.

Bonus question – do you have teams that count this work into velocity? using SP? How?

Note that the rationale for counting this into velocity is the “metric” side of velocity, not the planning aspect.

Its clear that this cannot be used to plan the release. It can, if you find the right way to account for it, reflect productivity of the team around this kind of work.

Leave a Comment

Invest in your Product Owner

June 14, 2009 at 11:29 am · Filed under Uncategorized

Getting the user stories on the right size, in the right format, in essence getting to the sprint in a READY-READY form (READY actually means READY, not make-believe READY…) requires a lot of cooperation from the Product Owner/Manager. He should understand the value he gets if he INVESTs in stories/features, because it DOES create work that he’s not used to. In some cases you will have a hard time getting to this level of detail from your Product Management, so you’ll need to create a Product Owner that proxies and fills in the blanks – usually a Business Analyst, Designer, Architect can help in that aspect.

 

The biggest challenge is if a Product Owner/Manager doesn’t think he can get any business value from small granular stories, and that “he needs everything – all features, and all requirements in all stories”. In that case, your biggest impediment is that the PO doesn’t believe in Agility – and you should think what to do about that. I would suggest a discussion about Agile potential ROI for the business, driven by faster time to market, better adjustment to customer real requirements, and much better predictability and trust that the versions will get out on schedule.

 

On a side note, I see the lack of understanding/belief in the value of agility on the business side as a very common and very dangerous problem. Without the business side on board, the development teams will lose a lot of the reasoning behind some of the Agile practices/principles, which might lead to regression to lesser ways.

 

E.g. ROI for faster sprints without delivery to the customer or PO coming for a demo – I believe they still have value in having a fast feedback cycle, even if internal, and even if used mainly for the team improving its performance. But its clear that the ROI will be a lot smaller than if the sprint result is actually taken by the customer or other groups in the company, both to earn money, as well as give much better feedback.

 

 

 

 

 

Leave a Comment

Big is bad, small is good!

June 14, 2009 at 11:29 am · Filed under Uncategorized

While a lot of what affects an agile team is within the team’s scope of responsibility, the key antipattern I’m talking about today sort of isn’t…

A big factor on whether a team can be effective is the size of stories/features on its backlog. A lot of good things happen when stories are Small (See the S in INVEST). A lot of bad things happen if they’re too big.

Lets look at how it looks when the stories/features are too big (team takes more than a week or so to start-to-finish them)

Teams cannot achieve real flow – testers are idle waiting for a long story to be developed, then are stressed to test it, since the end of the iteration/sprint is near.

Since there is a tendency of individuals to want some ownership of at least a story (if not a module), assuming big stories, an iteration/sprint will look like a mini-waterfall, with the developers each taking a story, all major stories getting into testing about 2/3 of the way into the sprint, and we lose the ability to control the sprint scope, and left with either making it across the finish line after managing to catch all defects and fixing them for all of the stories, or we are left with a sprint which is unsuccessful. The burndown chart of such a team will look like the one below.

 

 

 

 

For some really big stories, its not even clear how to finish them in one sprint, so teams start to have sprints for “Design”, “Coding”, “Testing” leading to really a waterfall across sprints.

 

With both in-sprint and across-sprints mini-waterfalls the mains problems are visibility and ability to change priorities or adapt to new requirements.

From the moment you start working on a story/feature, it becomes WIP – work in progress. Your aim should be to minimize this. WIP is Waste, that becomes apparent in the cases your Product Owner comes and says that this feature is now not the top priority anymore and he needs something else instead, or that after seeing a demo first time at the end of the sprint, he has a lot of changes in mind that you would have liked to have known about before finishing all the work.

The visibility problem is due to the fact that the real measure of progress is Working Software. Knowing that the design task is done and we are in coding is nice, but after many years developing software we don’t trust it that much. We prefer seeing working software frequently DURING the sprints.

 

The one potential problem of really small stories, is that they become a unit of business value that doesn’t mean much for the Customer/Product Owner. The drive for “Minimum Marketable Features” adopted by Kanban is to have slightly bigger stories, something you would mention in a product blog for example. There’s a fine balance that needs to be managed here.

Leave a Comment

The cost of iterations applied to Kanban as well…

June 10, 2009 at 6:03 pm · Filed under Uncategorized ·Tagged , ,

My latest blog post was about the costs and challenges of iterations, as well as what to do to overcome them.

One of the other things I’m working on is Kanban. I believe Kanban is a great fit to many teams and situations. Specifically doing Scrumban is a great way to get the benefits of Agile project management together with the Lean Flow Kanban provides. If you strive to achieve a stream/flow of value, you face the same challenges of getting to the minimal batch of work you can live with, and the challenges are quite similar to what I described above.

One difference is that if you DO have bigger features/stories from time to time, with Kanban you do them as fast as you can, but you don’t have the challenge of fitting them into iterations.

This is an advantage and a problem. The advantage is that it feels more natural.

The problem is that teams can fall into the “comfort zone” of keeping the features big, and doing mini-waterfalls on them.

Both with Agile as well as with Lean/Kanban the best solution is on the business/product owner side. If HE breaks the requirements/features into smaller stories/Minimally-marketable-Features(MMFs), the team will execute and deliver faster.

I haven’t thought this through, but my gut tells me that on the engineering practices side, Kanban requires about the same approach as Agile/Scrum in order to reach a high ROI.

What are your thoughts?

 

Leave a Comment

Iterate / Inspect and Adapt – nice in theory…

June 10, 2009 at 6:00 pm · Filed under Uncategorized ·Tagged ,

On paper, it all makes sense. You iterate in order to deliver business value as early and frequent as possible, and to learn as early as possible about mistakes or opportunities, both in what you build as well as how you build. So far so good.

Now, there are several things you hear from teams starting to work in fast iterations:

  • We cannot really accomplish any meaningful amount of work in this short time. Look at the features we’re asked to work on, no chance we can finish that so fast…
  • Wait – you mean we actually want to have this potentially shippable every iteration? That means we need to have it stable. In order to reach stability we need to do a test cycle. We need some time to do that. The term “Feature/Code Freeze” usually comes up at that point. See my earlier post about this.
  • Can we do design in one iteration, coding in another, testing in yet another?

All in all, if what you are looking for is a way to surface the heavy large batch stuff in your engineering organization, look no further than to raise the idea of fast iterations, not to mention to actually start doing them… ;-) Lucky for us, when we implement Agile/Scrum/Lean, that is exactly what we are looking for.

At this stage fast iterations trade some lost productivity for the gain of early ROI and better visibility of project progress, requirements changes. In Agilesparks, we call teams at this level “Scrum Level 1″. In some cases, at this level the cost and benefits are not that far from each other…

Its crucial at this point that the team/organization transition to a place where the lost productivity is negligible, while the early ROI grows. This requires both reducing the cost of the small batches as well as pushing the product to its customers more frequently. Without these two actions, it will be hard to justify continuing to pay the price of fast iterations, and some regression to long iterations or lower chance of shippable product will ensue.

How do you reduce the cost of small batches?

One of the keys is to introduce Continuous Integration with a fully automation regression suite reduces the price of testing.

Tomorrow I’m talking in a Test Automation Open day about this and related concepts. You are welcome to check out my slides .

I’ll continue to write about this subject in the future. I believe its key to making Agile work in real life.

Comments (1)

Agile antipattern: Code freezes during each iteration

June 4, 2009 at 9:54 pm · Filed under Uncategorized ·Tagged , ,

Bob Hartman, from the Agile for All blog writes about the agile antipatterns insanity – continue doing the same things that always fail, thinking they will work better the next time without changing anything.

I agree with every word, especially with the pattern of testing late, and code freezes during each iteration

I see this on many of the teams I’m coaching.

Go read what Bob has to say…

One reason I hear from teams that Bob didn’t mention is that testing earlier would mean testing time and time again the same areas leading to Waste (assuming you acceptance test a user story, then another user story, both in the same area).

As someone who likes to think in Lean terms, when a team throws Waste at me, it usually makes me proud. In this case though, its the other way around I think:

  • First, assuming reasonable engineering skills, the amount of codebase rework between these user stories will not be high, so the need to repeat testing for regression will not be very high.
  • Second, if you DO have a need to regression test, fine, automate it and make it cheap to test as many times you want, inside your CI environment.
  • Third, on the acceptance test side, with reasonable testing design skills, the tests for each of the user stories should not have much in common, so there is no waste here as well

On the contrary, to leave a user story untested for any period of time, is WIP waste.

You should test, fix bugs, before moving to other user stories, or at least while working on the next user story but not
the next iteration.

That was my line of thinking.

What do you think?


Comments (1)

agileblog 06/04/2009

June 4, 2009 at 3:32 am · Filed under Uncategorized

  • InfoQ: Pulling Power: A New Software Lifespan

    tags: lean, design, agile, agileblog

    • how Kanban metaphor from Lean manufacturing and the Feature Injection template play into Behaviour Driven Development, working together to help us identify the most important software, reduce unnecessary artifacts at each stage of development, and produce the minimum necessary to achieve a vision
    • The artifacts signal each role to create further artifacts until the vision is implemented and the business value is earned
    • “Generating reports,” he says, “is like lead. It’s easy to work with, and it’s cheap. It’s also heavy, worthless, and drags you down. Developers sink a lot of time into writing report software. Why? Buy it, install it, hack it so it works. Use Excel. Don’t spend money writing report software, unless you’re the kind of company that sells them to other companies.

  • Resources | limitedwipsociety.org

    tags: agileblog, kanban, limitedwipsociety

Posted from Diigo. The rest of my favorite links are here.

Leave a Comment

agileblog 06/03/2009

June 3, 2009 at 3:31 am · Filed under Uncategorized

Posted from Diigo. The rest of my favorite links are here.

Leave a Comment

Older Posts »