In the second in this series of blog posts, I would like to tell you about my journey into metrics; what difficulties I had, what I learned about the use of metrics, and how metrics will help to improve the chance of successul change.
The third Kanban practice tells us to “Measure and Manage Flow”. When I started to use Kanban, I had my dificulties with this. First, I wasn’t sure whether it would be okay to measure performance of my team (hint: it’s about measuring the performance of the system, not the team) and second of all, I just didn’t know where to start. Nonetheless, I gave it a try and was confronted with the question: “What should I measure?”. Continue reading
After I had to pass on last year’s Kanban Leadership Retreat, I had the pleasure to attend it this year. Again Kanban leaders from everywhere were invited to discuss the future of Kanban in the beautiful town Mayrhofen in Austria.
Arriving Saturday with my wife and child we first enjoyed Mayrhofen, which is truly worth a visit, before the Kanban Leadership Retreat started on Monday. There were a lot of people I knew from blogs, twitter or last years LKCE in Vienna. Meeting all these interesting people in Person was worth the ride.
Every single attendee had something to share, discuss or contribute. Sessions were a nice mix of presenting new ideas, challenging the status quo, learning from others and creating new things.
The sessions I especially liked or found helpful were
- Models by Mike Burrows feat. Arne Roock
Mike told us about Influencer, GROW, A3 and Pyramid Principle, four models he uses frequently. In the end we had a discussion about the meaning of the “Use models…” Kanban practice.
- Mapping the Kanban Universe by David J. Anderson
Resulting from another session on the first day. David and some others decided to build a map of the Kanban universe as we as a community see it. The picture below shows the session’s result. I am convinced this is just the beginning and the idea will evolve over the year. Actually discussions already started
- Lean Forecasting by Troy Magennis
Troy’s session was the most amazing one to me. The stuff he talks about and how he tells it must be described as groundbreaking! I have to admit I didn’t understand all of it in detail(language barrier and a lot of math), but I understood enough to get the impact his stuff will have. I’m looking forward to see him again at the LKCE13 in Hamburg.
- Flow Manager(or whatever you want to call it) by Florian Eisenberg feat. me
Florian and I brought up the hypothesis that every successful Kanban implementation has someone we called a flow manager. The flow manager as we mean it is somebody taking leadership. To be very clear we are not talking about a role in Kanban. We wanted to know, if others also see this pattern and how we spot these people and when spotted how should can we support them.
Thanks to all people making this event the great event it had been. Special thanks go out to the organizers. I hope I could give you a nice inside into the Kanban Leadership Retreat and who knows maybe we will meet next year in Portugal.
If you any questions or just want share your thoughts to one of the sessions, don’t hesitate to comment. I would love to hear what you think especially about the flow manager.
At the beginning of the year, I introduced Kanban to two Scrum teams I worked with as a ScrumMaster and one problem I faced was how to integrate tasks into the Kanban board. Practicing Scrum for more than one year, the teams were used to tasks and refused to drop them, because they saw tasks as very helpful in order to see there progress and synchronize their work. I agreed with the team and didn’t want to change to much in order to avoid resistance as much as possible, but at the time it seemed there was no room for tasks and stories on a Kanban Board. Of course we found a first solution and started to advance from there, but somehow I wasn’t able to write it down, until yesterday.
That’s because I received an email from a friend, an Agile Coach, asking me for advice on how to tackle pretty much the same problems I had when starting to use Kanban with the Scrum teams. Needless to say I answered his questions and I guessed there are probably more people out there having trouble with integrating tasks into their Kanban System. So I decided to finally revive my blog and share my experiences in switching from Scrum to Kanban and hopefully help others with it and maybe get some more ideas and feedback. Here is my solution to how to integrate tasks known from Scrum into a Kanban board.
I just arrived home from this year Agile Coach Camp Germany in Rückersbach close to Frankfurt and although I am pretty tired I want to give you a small expression of this great weekend.
The theme of this year Agile Coach Camp was “The inner fire works!” and every single participant helped to make the fire huge. There were a lot of sessions proposed, all of them interesting and exciting and some of them were proposed even for the evening in the bar. As I said before, the fire was huge. There are three sessions I want to mention and tell you a little bit more about. Continue reading
Couple days ago, I had the pleasure tweeting back and forth with Russell Healy the inventor of the game getKanban. David Anderson was playing the beta of getKanban v3 at his training in London and gave Russell some feedback.
Thinking about it I decided to tell you a little bit about the game as some of you might not know it. Continue reading
Last week fourteen people all especially dedicated to agile and/or lean met in Munich to discuss Jurgen Appelo‘s idea of an Agile Lean Europe network, short ALEnetwork. The meet up was not a Munich phenomenon. Not at all. Everywhere in Europe people have met to discuss the idea and gather some information on what ALEnetwork is to them, what they expect and especially what they don’t expect.
The position of the Luxembourgish community on ALEnetwork is an awesome expample of ideas people came up with. Not only did they meet, Pierre NEIS also made the following very cool slideshare. Continue reading
Last week I attended an awesome Kanban Training with David Anderson. At the training Jens Coldewey from it-agile came up to me and asked if I would be interested in starting a Limited WIP Society Group in Munich like Arne Roock and Bernd Schiffer already did in Hamburg. Unquestionably I said YES! :)
We are planning on having the first meetup at the end of May beginning of June. Right now we are looking for a room to fit around 20 – 25 people and has enough space for Open Space. Preferable a room we can use on a regular base like every every 4 – 6 week. Please, let me know if you know a place.
So if you would like to attend and don’t want to miss it, join our mixxt group at limitedwipsocietymuc.mixxt.de and follow us @limitwipmuc. We will announce the first meeting early enough so everybody has the time to schedule it.
If you are interested, from Germany, Munich is still too far, but Hamburg would be okay, join limited-wip-society-hamburg.mixxt.de and follow them @LimitedWIPSocHH. Again nothing you would be able to join? Take a look at the official limitedwipsociety.org site there you will find a list of all local groups around the world.
Looking forward to see you at the Limited WIP Society Group Munich!
Update: Finally the first meeting is arranged! Meet us at the CONRAD-HOTEL de Ville in Munich on 23rd May for more info visit Limited WIP Society Munich
In my last post I wrote about how the Product Owner can help to increase the quality of the software without crossing the line, staying in the framework given to the Product Owner role. Although I wrote, there are plenty of articles about how developers can increase software quality, I still want to do a follow up on my last post. Just to have both sides covered.
So what do we have in our toolbox for developers? First there are plenty of tools and it would take me a while to describe them all. Therefore I will elaborate on just a couple of them in detail.
I assume the fact we are talking or thinking about quality means we want to write good software and don’t want our customer to find any bugs. Therefore we are all testing our software. It starts with the developer, who will run the code he just wrote and ends with somebody testing the complete software. I am writing somebody, because some people might not have dedicated testers in their project. That’s the point to start at – get a tester!
Wait, wait! Don’t leave!
A week or two ago I got the feeling of hearing product owner complaining about software quality and developers talking more and more about fixing bugs and telling the product owner in the sprint review there “are still small things to do, to finally be done”. To be sure if my feeling was right, I asked the product owner for their opinion regarding the quality of the delivered software. I didn’t have to wait very long to receive answers to my question every single one telling me the same in different wording. In short “Yes quality sucks!”
Everyone dealing with Scrum or Agile Methods stumbles sooner or later over Extreme Programming practices like pair programming, code-review, continuous integration, unit- and acceptance tests, refactoring and test-driven development(short TDD) to name the best known. There are some more like behavior-driven development(BDD) for example and all practices mentioned are intended to help developers write better code. Continue reading
My trip to the Scrumtisch in Hamburg really was a worthwhile trip. Thanks to Christian Dähn we had a great time with a lot of interesting discussions. Christian tried an open space for the first time and it worked great. Two topics where especially interesting, both addressing a similar issue, whereby they ended up being discussed in the same breath.
1. Is an advanced self-organizing team still in need of a Scrum Master?
2.How much pressure does a team need?(Evolved to: How do we keep the pressure on the team and whose job is it?)
The thought behind 1. is that if a team is self-organizing at the highest level, what’s the job of the Scrum Master? Is it confined to moderating meetings the team has or not even that because the team takes care of it, too?
This thought is followed by the second topic. The topic owner suggested that a team advancing in a project is simultaneous getting unchallenged and therefore lazy. Continue reading