I attended the Leader’s workshop of Mary and Tom Poppendieck. I already read their books. However, I thought it would be very useful to attend a two days workshop covering lean management. I was right, it was very useful and gave me new energy to start working to implement lean thinking at RES Software.
I made some notes for myself, thinks to think about, etc. I would like to share them with you instead of keeping them only to myself (I could also share my Evernote Note with your…), maybe it triggers you to think about things. To be clear, all credits go to Mary and Tom Poppendieck! There is no real structure in this blog entry, just a mind dump of my thoughts that could be useful to trigger something in you.
In the book Outliers, author Malcolm Gladwell says that it takes roughly ten thousand hours of practice to achieve mastery in a field. Did you ever met a developer or tester who worked in IT for five years and called himself a principal? Let’s assume, a developer or tester is able to work 5 hours per day on software development of testing. 52 weeks a year, 52*5=260 potential working days, 25 days holiday (Yes, I know, we should not complain in the Netherlands), results in 235 potential working days, training, illness, and may public holidays, results in 230 working days. 230*5 = 1150 working hours per year. 10.000 / 1150 = 8,6 years… it will take at least 8,6 years for someone to become a master in his profession. Next time you meet someone who calls himself a principal with 5 experience in IT, you know he can’t be a principal.
As we all know, you learn when you make
One of the attendees in the workshop said he asked his team members regularly how much happy time they had during the day. That’s a question that could trigger some interesting answers… I would expect that when a developer has to answer this question he will count all programming hours as
The Chinese wishers games proves (I know, not scientifically) that handovers cause loss of information. To prevent this, make you sure have all the required disciplines in your team or at least close to your team. The more handovers, the more loss of knowledge. Something like the graph below.
As independent software vendor (ISV) knowledge is your greatest asset, knowledge of the domain, knowledge of our software, knowledge of our processes. This knowledge in the heads of your employees. Therefore, knowledge == employees. We should make sure people like working at RES Software, and fortunately they do :). When employees leave, knowledge leaves. When knowledge leave, real important asset is leaving.
Some nice one-liners, or interesting statement to make you think:
- Tom Poppedieck: “Source code is not for computers, it’s for feature developers to change.”…
- All code that you write without an automated test harness is automatically legacy code…
- Conway’s Law: “Structure of your organization is displayed in your code”…
Did you hear about the three motivators according to Danial Pink? Watch this video, very interesting and you could use it to convince your management that giving extra awards based on production targets is not helping.
You should try to find T-Shirt shaped people for your people. T-Shirt shaped people? A person who is above average in for example testing, but is also capable of doing some basic programming and (because he is a native speaker of another language) he can do translations. This person is able to help also other disciplines in the team.
If you are interested in how to organize a large project with Kanban and Lean ideas, read this great paper of Henrik Kniberg. It’s similar to Scrum From The Trenches, but this time about Lean.
Did you ever happen to be in a project that missed it’s deadlines? That is turns out nobody believed in the deadline, but no one spoke out his opinion? A nice idea to prevent this comes from Henrik Kniberg. Vote how realistic the goal/deadline is every (two) week(s). Ask all team members to raise the number fingers they believe the goal can be met, 5 is absolute, 1 is totally not realistic. Write down the score and discuss the score, why does a person don’t believe the goal is not realistic? Did you forgot about something, do you need extra capacity, redefine the scope, etc. One of the important things of lean is to make things visualize, this action visualizes the trust in of the team members in your project. It would be strange if you have a goal and no one of the team believes this goal is realistic…
I often try to explain to people why projects based software development is different than product development software. Mary and Tom Poppendieck gave me some new arguments to explain the difference. The key, in my opinion is, that product based companies go for increasing market share in the long term. A product based company is not interested in short term strategies, your goal should to be in the business for the 47 years. For a project based company success is most of the times defined as keeping cost/schedule/scope under control. It’s not about a long strategy. The project ends but when the project ends the software doesn’t end…
So far my public notes… if you have the opportunity to attend this workshop in the future I would advise you to do so. If you have any questions or you disagree with me, please comment. This gives me a opportunity to learn!