“This format is amazing. All workshops should run this way”.
This is the comment we heard from a recent participant of our recently created Agile Boost Camp format. In this workshop we run a truly agile-style 2 days where the participants pick and choose topics they want to address. We adjust the plan along the way, we ran short timeboxed Pomodoro style sprints and consider next steps after each. Continue reading →
As a Kanban Trainer I often introduce people to the Kanban Method for evolutionary change and the aspects of evolving system design and how they drive improvement. I’ve been looking for ways to make this introduction and exploration of the Kanban Method a more interactive experience. I love Russel Healy’s Kanban Game both in physical and online form. It is THE best way to experience how to manage the flow of a Kanban system using a GIVEN system design. I see it as an experience of “Visualize”, “Limit WIP”, “Manage Flow”.
Now what do we do about “Make policies explicit” and “Improve Collaboratively, Evolve Experimentally”? Sagi Smolarski (who recently joined the AgileSparks ranks) and myself have been working on creating an experience that focuses on experimenting with policies seeking improvement while using ongoing quantitative feedback. Sort of a dynamic accelerated “Ops Review” simulator. It is still under wraps but we are readying it for a private beta release which will happen very soon. An example scenario would be to start with a certain combination of capacity, demand and system design, and try to fine-tune the system design using policies like WIP limits, definition of done for queue handoffs, swarming preferences, etc.
The AgileSparks Flow Simulator – v0.1
Mastering and honing a “static” context will not be easy, as we are trying to model several aspects we encounter in the real world such as the downsides of “too many cooks in the kitchen”, costs of delay both for value erosion as well as cost increase and chance for defects. Finding the right WIP levels for a system will not be easy.
But then at some point we will add “dynamic” transitions into the equation. Can “Slack” help you improve your capabilities? Will you now need to fine-tune the system towards a new balance? Is it worth allowing this “Slack” or squeezing as much value now from the system?
Some of the above is in our “To do” column, some of it in the “WIP”, and some of it already “Done”. I’m really anxious to be able to show this to the Kanban Community and whoever is interested in learning about the Kanban Method. If you are interested as well, let us know
I recently had a couple of weeks with a few activities related to “Agile Testing”. “Agile Testing” for those not familiar with it is the name we give to the set of thinking guidelines, principles and practices that help run the testing aspects of product development/maintenance in a more effective way under an Agile delivery approach.
A question that came up while presenting the concepts today at a client was “What’s broken? Why do we need this?”. While my presentation covered some of the rationale the question made even more clear (not that I needed any convincing…) that the guided evolutionary approach to improvement is a winner. If they don’t yet feel the need/pain there is a lower chance they will do something about it.
The question comes up – why don’t they feel the pain? Or alternatively, maybe they feel the pain but don’t associate it with the need for “Agile Testing”.
So I wanted to briefly touch on a few questions/indications that you might need to pull ideas from “Agile Testing” as your next improvement step.
Some indications you might need to look at “Agile Testing”
You applied WIP Limits and testing is becoming a bottleneck. Not once or twice, but quite consistently.
You agreed to include test automation as part of the “Definition of Done” and you are seeing a queue building up meaning the automation is slowing the entire process down, creating significant slack for the people NOT doing automation.
You find a lot of defects which send you to rework technical design due to lack of mutual understanding of the functional requirements / stories, or you find yourself leaving things ugly since there is no time to do the rework – earning you some customer feedback that you are not really providing high quality deliverables.
You are not able to run a very granular flow – everyone claims smaller stories are not useful since the overhead to deliver them to testing and test them is so high. Let’s just keep using bigger items and deliver to testing not more than every 1-2 weeks.
People feel that the test automation approach you have now doesn’t cut it. The total cost of ownership / lifetime costs are very high, and even though people understand the need to have automated coverage in order to integrate often, they are very frustrated by the costs.
Testers are confused. Do they need to be automation specialists? Domain experts? Technical experts? Supermen? In this Agile Whole Team approach where there is flexibility and collective ownership – what is their unique value? what should they focus on?
My latest presentation touches on some of the reasoning why these issues come up when going Agile, as well as introduces how “Agile Testing” can help. For more about this you are welcome to join me at one of the upcoming Agile Testing workshopsAgileSparks runs in Israel and Europe. Contact us for more information.
I’ll be running our first Accredited Kanban Training workshop on March 21-22 in Herzelyia, Israel. This is our highly-praised Kanban training which has been fine-tuned in the last months to align with the LKU Standard Curriculum. As a student in the class this means you are getting a high quality Kanban Curriculum aligned with the leaders of the community, from an accredited trainer recognized in the community…
I decided to get back to Prezi as an alternative to Powerpoint. Its capabilities seem to be a good match for my kind of materials – Visuals of boards, charts, etc. where you want to zoom in on details, show flows, etc.
A specific opportunity is coming up that is making that even a better idea, so I finally took the plunge 2 years after my last real use of Prezi I dove in again. So much fun, spiked with a few frustrations on missing features. But being a Lean coach, and someone talking about Lean Startups, I can recognize effective MVP (Minimum Viable Product) when I see it. The iPad viewer app is one… (don’t expect it show PDFs just yet 😉