This is a great book from Gojko introducing Impact Mapping. It is short and easy to read, but address an important and often overseen area when delivering software: What impact are we targeting and how do we measure it?
This book will not give you a very detailed recipe of techniques, but it describes the basic thinking and provides some good examples.
A valuable technique for any Product Owner or other person responsible for derivering business value.
After talking with different people, I have been reflecting about the situation where many companies seems to adopt agile techniques to be able to deliver faster and with higher quality (more gas for the same buck), but it seems like they are not driving more agility into the organization or into the products. They are not able to rapidly respond to the many emerging opportunities. It seems like the balance is more on delivering the expected and planned requirements rather than regular inspection of each completed Increment, collaboration with customers and be able to rapidly make changes and optimize business value.
Program Managers or Product Owners should do more than just deliver the approved project or approved requirements. Maximizing the business value and optimizing TCO (Total Cost of Ownership), are areas that to often are not done in most organizations. Recently I have talked with different business people who think a best practice is to have a Product Owner for a team doing support and hotfixes and another Product Owner for another team working on the new release for the same product (often called a new project). They had not considered the whole value stream of activities and how they were combined. Having a Product Owner responsible for the product, TCO and full value stream, seems like an alien thought in many larger organizations.
We need to change the sub optimizing thinking to enable Agility in organizations and move beyond the predictability mindset.
Frankly speaking, it did not expect Microsoft and TFS releases adopting agility and starting a journey on continuous delivery. I heard about MSFT people that talked about the radical change from previously doing development in 1 year followed by stabilization in 1 year to now be able to release every 3rd week to TFS as a Service on TFSpreview.com. I look forward to follow how this will evolve in the future including the pricing model and integration with Azure.
Imagine the new opportunities for many Enterprise system, if they move into a regular deployment of functional based releases to a hosted solution, and also be able to deliver their product as a service to customers. This could help them respond rapidly to customer feedback and opportunities and deliver much higher business value.
At the TFS Erfa group meeting at Microsoft Denmark in Hellerup, Rasmus Selsmark and Kim Carlsen from ScanJour presented highlights from TechEd 2012 (Amsterdam). Rasmus also did a very impressing demo using tfspreview.com to create a new TFS project with a web solution and linking it together with deployment to a Azure. Done in less than 20 minutes and then ready for continuous deployment to the production site running at Azure.
It looks like there are many opportunities for both startup companies and larger companies using tfspreview and Azure.
Rasmus has blogged more about TechEd 2012 on rasmus.selsmark.dk.
Rune Abrahamsson from BRFKredit talked about CUITe (Coded UI Test enhanced) Framework and how they have used it. It will be interesting to see how CUITe will evolve in the future.
Ole Rich Henningsen did a short demo of the new Scrum 2.0 template in TFS 2012 and it looks interesting and easy to use.
Many team and organizations are talking about doing Scrum.
The Scrum Guide describes the basic rules of Scrum and it actually only takes 9 questions to answer if your are doing Scrum or not.
If you can answer yes to all of the 9 questions, you are doing Scrum. Great. Many teams are doing some of them and still creates great software.
Still, Scrum can be played in so many different ways depending on context, the organization, products, projects etc. and Scrum can help you be more Agile. It can help creating Agility in the organizations to rapidly respond to new opportunities from customers and create emerging solutions with much higher business value. This also requires the Product Owner to think more on business value and Agility.
Based on my experience, many teams have challenges to do question no. 7 “Create a usable and potential releasable Increment every Sprint”. It requires a good infrastructure, good test automation and the Scrum Team working very well together as one synchronized unit sharing a strong Definition Of Done. Not trying to do too much, but doing what the whole team is capable of delivering. If not doing no. 7, the Product Owner can not rapidly respond to new opportunities and changes.
The Lean Startup movement is moving around the world and I have done a number of presentations at my work at Scanjour to establish a common understanding of the concepts. We have also started to look into how we can utilize Lean Startup thinking in our product development to create more data driven validate learning. It will be really great, and I expect we will get very good results from that approach.
The presentation I did at Scanjour can be seen below (it is continiously being improved based on feedback).
At ScrumForum.dk events in Marts 2012 I did a presentation about Scrum and Agile in a Distributed setup. Find the Prezi presentation below.
I started a practice with my daughter, Silja, last autumn, where we did a check-in and reflected on the day and what had happened in school. After she started in first grade, the typical answer when I asked how school had been was: Fine… When I asked her what she had done in the school, she could not remember specific events.
In the beginning of first grade, she had used a practice a couple of times, where the teachers showed the kids to evaluate different activities by rating them on 1 to 5.
So we extended that practice and I started to ask her how the day had been on a scale from 1 to 5 (she likes to have 1 as the best possible and 5 as a really bad day). Then I ask her what should have been different if it should be a better rating and she starts to talk about events during the day that she did not like. Suddenly we have a conversation about events during the day that I did not hear about in the past and it feels much easier for her talk about them. Often it only takes a couple of minutes and we do the talk when time feels right and we can just have the 1:1 conversation. I don’t judge the events but let her talk about the different experiences during the day.
A typical conversation would happen like this:
- Me: Silja, have has you day been today.
- Silja: : <thinking> I would give it a 3
- Me: Okay, and what should have happened for it to be a 2?
- Silja: <thinking> I god sad in the morning because of … and when we had the break this happened… and after lunch we did this … that was not fun… <etc>
- Me: <silent> okay, and if the day should have been even better be a 1, what should then have happened?
- Silja: <thinking> then we should have done this … and this …
It is amazing how this simple talking protocol has established a way where Silja and I can reflect on her day at school.
I have used similar reflection practices with agile teams and it can be a very powerful tool to focus the reflection.
If you have kids, try some of your agile thinking not only at work but also home.
This week I watched the follow up User Story Mapping slidecast from Jeff Patton (UIEpreviews). On one of the last slides I could see the picture (to the left), where a book about User Story Mapping is expected to be available in winter 2011 (by Jeff Patton). This is so great. Last week at the ALE2011 conference in Berlin I talked with Rachel Davies about Jeff Patton and he should write a book on this subject. I can’t wait to dig further into this area, since I have seen it is a valuable way of working with User Stories. It creates the model that different roles can discuss, test and understand before starting implementing the stories.
The ALE2011 Unconference was last week, so now it is time for some Hansei.
The week before the Unconference, I got an upset in the back, so I had to have some intensive chiropractic treatments on Monday and Tuesday, before I could fly to ALE2011. At the Unconference I had to go to my room and lay down with my “Ice Pack” a couple of times during the day, and when I did a talk about Offshore Software Patterns, I was a bit afraid to move around on stage.
But the Unconference was GREAT. So many people from all over Europe with energy, passion and just wanted to share and discuss. I would not have missed it.
It is amazing how the teams have organized this event. Thanks!
What was good?
There was so many things that was great at this Unconference, some of the highlights that comes to my mind are
- The was an Unconference
- The combination of talks, open space and lightning talks, was a great blend
- Dinner with a stranger, was a great way to meet new people and have time to know them better
- 3 great keynotes, especially the one from Dave Snowden was inspiring and started a lot of reflecting
- An amazing retrospective with about 200 people
- All the sharing and discussions in between sessions, at lunch time and at the bar etc.
- A lot of great people with interesting stories from all over Europe
- All participants with deep practical experience in Agile
What should be reduced?
- People with larger egos talking about what they have done and how good they were (there was only a few J)
- I should have use the “The Law of Two Feet” and not staying at Open Space sessions when I felt it would be more valuable to go to another one
- Some open space sessions where more “One man talking”, not people sharing and discussing
How could the Unconference be even better?
- More sharing and stories related to Lean areas, since Agile was rather dominating
- The retrospective round from each of the 8 groups (about 200 people) took a long time and the energy was going down. Rather we should have jumped directly to the “Remember the Future” exercise.
- Have all the rooms at the same floor, so people are more co-located
- More sharing of cases from different companies
- Have more talks with pair-speakers from different countries
What did I bring home?
- A lot of energy
- Inspiration to start doing more writing
- New friends from the ALE Network
- A couple of new books to get on my Kindle
- A nice PairCoaching mug, the right size for a double espresso (using it right now)
- I want to learn more about the Cynefin model from Dave Snowden. It has already been on my reading backlog for a couple of years, but now I moved it up
- I want to learn more about Beyond Budgeting and how it has been used in different companies
- We will now boost the ALE|Denmark group even more and the goal for next meeting by end September is to create ideas for a product.
- @HansBaggesen and I will do some Ale2011 Sharing sessions at Fujitsu DK
- More reading, writing, sharing
At ALE2011 I did a open space session with Alexey Krivitsky about “Share your stories and advice for not building walls in Software Offshore”. There was a lot of interesting stories from people both working onshore and offshore in different organizations. Without filtering or any additional comments, I will list the 13 advices that where suggested by the participants (I hope I got all reasonable correct).
13 Advices for not building walls in Offshore Software
- See at your offshore teams as your own developers
- Have the offshore teams working on projects and products and not only simple tasks
- There have to be a change agent in the onshore organization on all level to facilitate the offshore setup
- Have a Offshore coach to help the offshore team(s)
- Have a very good Product Owner that understand working with agile and Scrum
- Have small offshore teams
- The Product owner must visit the offshore teams on a regular basis
- Make sure everybody understands both the onshore and offshore culture
- Hire a local agent to work offshore with same background as the offshore team
- Involve the Offshore team before going agile
- Do complete financial calculations before starting offshore
- Build motivation and domain knowledge by showing the offshore teams how their software is used (the software they are developing)
- Find a good offshore partner to have a long term relationship
Alexey is also capturing ideas, concepts etc. on http://www.scrumoffshore.net/ and I will start do some structured writing about “Offshore Software Patterns” for building a global system at http://blog.lean-agile.dk/offshorepatterns