Tag Archives: agile

Read my article on the journey of a Tester from waterfall land to Agile/Kanban land (in Hebrew…)

Estimated Reading Time: 1 minute

A couple of months ago I ran into Think Testing – a new magazine for testers in israel (published in Hebrew).

I found it very interesting, and decided I want to contribute.

My article has been published in issue number #3. It tries to provide some insight on the experience of a tester when his organization/team decides to go Agile.
(Update: article no longer available in original location so use slideshare now)

I also like the design work they are doing for the magazine. It has a real professional aura.

Let me know what you think.

Hag Sameach!

 

UPDATE: An english translation is now available at slideshare

What do I need to know to start being a Product Owner?

Estimated Reading Time: 2 minutes

 

What is the basic role of the Product Owner?

http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell (New)

http://scalingsoftwareagility.files.wordpress.com/2009/11/ch-11-role-of-the-product-owner-rev-12.pdf
http://www.agileproductdesign.com/downloads/patton_product_owner_role.ppt

Starting with user stories:

User stories are the most common way to handle requirements in the agile world. One of the first things you’ll need to do as a product owner is familiarize yourself with them, and start to provide them to the delivery team.

Mike Cohn on Effective User Stories – http://www.mountaingoatsoftware.com/presentations/42-effective-user-stories-for-agile-requirements

User Stories Primer http://trailridgeconsulting.com/files/user-story-primer.pdf

Recommended Book – User Stories Applied by Mike Cohn http://www.mountaingoatsoftware.com/books/2 Cover

User Stories Advanced Techniques

After you got the basics nailed down, go to some advanced techniques for managing and manipulating user stories:

  1. Techniques for splitting user stories http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
  2. Story Mapping Technique  http://www.agileproductdesign.com/downloads/patton_user_story_mapping.ppt
  3. http://scalingsoftwareagility.wordpress.com/category/agile-requirements/

Some material on Agile Release Planning:

  1. http://www.agileproductdesign.com/downloads/patton_incremental_releases.zip
  2. http://www.agileproductdesign.com/presentations/index.html (Patton in general)

Some process-related material:

Product owning also requires effective interaction with the agile process. Concepts like READY and Flow and how to effectively interact with teams are as important as the quality of the requirements themselves. Actually, in some cases, having the right process will help focus on doing the right things at the right time and solve some conflicts and problems product owners have.

  1. Practical tools for the Product Owner: Focus, Value, Flow – http://www.scrumalliance.org/resource_download/1249
  2. The importance of READY Product Backlog for effective teams – http://scrum.jeffsutherland.com/2009/07/ready-dynamic-model-of-scrum.html

Scaling the Product Owner

If you are working in a complex enterprise environment, you might need to look at some advanced materials regarding scaling. I would recommend reading and understanding some ideas, and also seeking professional help by those experienced in these environments.

  1. http://blog.versionone.net/blog/2009/03/the-product-owner-team.html
  2. http://www.westborosystems.com/2010/02/onsite-product-owner/
  3. http://feedproxy.google.com/~r/OfficialHuitaleBlog/~3/q_19u5mfYog/single-product-owner-model-is-broken.html

Discovery

http://www.infoq.com/presentations/lean-product-discovery

In general, I recommend to all Product Owners/Managers I’m talking to these days to look at “Lean Startup”  to start thinking about the iterative learning associated with the Product Discovery process. Jeff Patton’s session above is a good introduction into this, but the whole body of work around “Lean Startups” is very interesting to Product people in general. You cannot afford to manage products these days and not be aware of it IMO.

 

Summary

I’m sure there are other great references out there, and I’d love to hear about them. But in the meantime, this is a reasonably comprehensive list, with the risk being a little too comprehensive. I would suggest you go top to bottom unless you have specific burning issues you need to skip to.

If you find this useful, tell your friends (and me!)

If you don’t, I’d appreciate hearing why!

Happy Reading!

Updates

Added the “Discovery” section on Feb 2012

Added Henrik’s brilliant short animated movie about Agile Product Ownership – October 2012

Why I think slack is highly important during an Agile/Kanban transition

Estimated Reading Time: 4 minutes

(Note, this post is about slack the concept not Slack the collaboration platform. Though Slack the platform is great as well. We use it at AgileSparks and love it, although it eats up some of our slack time…)

Actually, the title is wrong. I think slack is highly important during any change initiative where you expect continuous improvement of the process and practices. The importance of slack is not new. Not in manufacturing, and not in the Software Engineering world. One of my favorite books is Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco. Actually anything by Tom is a gem worth reading if you’re serious about managing Product Development organizations… But today I had an epiphany. One of the biggest challenges we face as consultants trying to challenge organizations to be more effective/agile/lean, is that the people simply don’t have enough slack. They don’t have enough time to meet with us. They don’t have enough time to meet and retrospect. They don’t have enough time to experiment. Experimentation takes time – you need to think about what to try, if you take a risk, there is a chance you will fail and lose time. Its very frustrating as a consultant/coach. You have so much to give, you see so many opportunities for improvement, you know that if the team will just sit in a room for an hour they will come up with ideas that can help. You know that if that Developer from the team has some slack time on his hands, he will think of a way to make that build run faster. That test automation suite easier to update.

My pledge to managers leading Agile/Kanban transitions
Please Please Please consider how to add slack to your system. Especially during a change initiative it will help you get the most out of it. People will be more engaged, you will get much more out of your efforts and budget. I pledge to try and convince my clients to do this…
Now that you’re convinced, lets discuss how to actually do it in practice. If you’re not convinced or think you have other ways to better drive this point, I’m all ears… and the post is open for comments…

To effectively use slack I think you need to do two main things:

  1. Account for slack in your resource planning.
  2. Have effective mechanisms to use the slack for the best possible purposes.

Accounting for slack in the plans This is quite straight-forward as soon as you convinced your stakeholders it is a worthwhile investment. Pointing them towards Google (20% time…), Atlassian (20% time and FedEx Day) and other companies using slack as a core part of their system, might help you. Technically, just reduce the resource capacity % in whatever method you are using to manage your projects/commitments. Another great way is to use the slack that is inherent to the plan/development process. What do I mean? For example – in a Kanban/TOC/Flow system the bottleneck doesn’t have any inherent slack. But upstream and downstream from it, if you work in Pull mode, you will find slack. This is because they can process faster than the bottleneck, so obviously there will be times they cannot process because they are bound by a WIP Limit (Or TOC Rope). In Iteration-based Agile this slack takes the form of some free time on the last few days of the iteration if you’re not the tester. In both these scenarios when you have slack, you can either throw it at the bottleneck’s current work, or use it in other ways.

Effectively using the slack
Now that you have some slack time, what do you do with it?
One flow/continuous oriented approach is the Google 20%. People simply have the slack to work on other things in parallel to the ongoing core work.
Another approach is to setup special events, like Atlassian FedEx Day. These events are a time where the entire team/organization is focused on slack kind of work, and it is probably a good idea to use those especially when starting, to kickoff the mindset that slack is a good thing, and show some examples of what can be achieved.
What do you actually do on slack time?
One type of activity is pushing the product forward in some innovative small ways that are off-road from the main track of the project/release. You need to be careful here – messing around with the core behavior of the product is probably not a good idea without the blessing of the Product organization…
I would imagine the google engineers don’t mess around with the homepage too much. They introduce their innovations via Google Labs, plugins, etc. Some ideas make their way into the mainstream product, some become mainstream products (e.g. GMail)
I wanted to talk about a second kind of activity – the one that pushes the capability of the organization forward. Here, your aim is to identify areas where improving can have an effect on the bottom line performance of your organization, and then find ways to improve there.
I discussed before some scenarios like this, but to reiterate the important point – you want to use slack to help Exploit your current system Bottleneck. Now, as I said earlier, one way to simply throw the slack capacity at the current work of the bottleneck. This will help tactically, but will not improve the capacity of the Bottleneck in any long-term fashion. You should balance the tactic solution with finding ways to spend slack capacity on things that will really make the Bottleneck more efficient.
What this means is that a lot of times, the resources working to improve the capabilities of a function, don’t even belong to that function. This is why cross-functional teams and a holistic end-to-end view of the Value Stream is so important… without it you can improve things locally but have zero (or even negative) effect on the bottom line.

The Ant and the Grasshopper – Application for product development

Estimated Reading Time: 2 minutes

I’m sure everyone is familiar with some version of the The Ant and the Grasshopper (or הצרצר_והנמלה)

While talking to a Product Manager today, I was asked “How come we always end up without QA resources at the end of the version” and was reminded of this tale. Most projects behave like the Grasshopper. Focusing on Features like Summer is endless, building a QA debt through the project/release.

When the Stabilization/End Game/Hardening time/Winter arrives, they find out they have a problem. Think of each feature as a child Grasshopper. They bred a family they cannot feed through the winter. They have too many features to take thru hardening, in a fixed time. (Yeah, Yeah, the metaphor only goes so far…)

Alternatively, in Agile/Kanban projects, we want to be the ants, always thinking forward, always staying in a sustainable mode, where we have enough food to feed ourselves and family throughout the winter, and don’t breed too much that you won’t be able to survive (here comes the part where you say – a lot of ants do die, its part of the plan, etc. – I have an interesting comment on that – related to Lean Startup and Discovery cycle, for sometime else)

What I love when I see it, is teams that start to understand this, where suddenly its a problem of the whole team to prepare for winter. Its not just a problem of the QA team anymore. The whole team starts to think about how to prepare better, and how to setup the right pace of features that we can sustain through the project.

I say to you developers out there – “To help testing be more efficient today is to be able to work on more features tomorrow”.

Remember – its either you think testability from the start, or you end up testing anyhow, under pressure, without the ability to really do something useful to help you, just focusing on survival mode.