Agile and Lean meets IT

Posted on Leave a commentPosted in management, process

Was making presentation about how we were transforming IT into service type instead of control type.

Conclusions

  1. Imagine you have to earn money. Perfectly shifts away your thinking away from “cost efficiency”.
  2. Avoid broad terms. Too much room for interpretation.
  3. Control scope. Be explicit about what you can do. Say “no” to things you can’t.
  4. Monitoring and Transparency. Best way to control things.
  5. De-centralize certain activities. Build for scale.
  6. Grow you process. Evolution vs adoption
  7. Know value flow. Local efficiency is not what you need

[slideshare id=54959255&doc=a1269492-f8d5-4ebc-820e-92b27d1d4599-151110160930-lva1-app6891]

Agile Saturday X – Metrics

Posted on Leave a commentPosted in management

Continue sharing notes from Agile Estonia event – http://agile.ee/ Previous post about Staff Liquidity

Metrics
  • Lagging metrics – the ones you can’t affect [e.g. weight]
  • Leading metrics – the ones you can affect [e.g. what food you take]
  • The best way to influence the team is to visualize the data
  • Avoid vanity metrics. Use AARRR metrics: Acquisition of customer; Activation – are the active? Retention; Reference; Revenue
  •  Don’t use metrics as target
  • Make sure everybody understands what is behind this data and how it’s gathered
  • Use balanced set of metrics, e.g. Revenue, Ability to do more work, Happiness of employees, Happy customers
  • Keep in mind the cost of metrics gathering. Will you be able to make decisions based on that?
  • Metrics expire!

Last part is going to be about improving the whole value chain. It was very interesting keynote by Mattias Skarin.

12 Principles of new organization

Posted on Leave a commentPosted in management

How are these principles applied in your company? Do you have modern management system? Let me know if you want to discuss this more or have any practical hints how to move that direction in the company with more than 5 people.

Leadership

  1. Orientation towards client – teams are seeking highest clients satisfaction level rather than achievement of fixed targets from the top management
  2. Responsibility – not central hierarchical units, but small network units are responsible for the results
  3. Effective environment – environment where team’s success is measured according market success, instead of internal fixed targets achievement
  4. Actions freedom – decentralized teams, which are directly working with clients, have all freedom to make decisions and take actions
  5. Management style – everything is managed based on clear and understandable values and boundaries instead of rules and fixed budgets
  6. Transparency – important information is easily accessible to everybody

Processes

  1. Targets setting – making challenging flexible targets, oriented towards continuous relative improvement instead of fixed targets defined for a year. You can call it a direction.
  2. Bonuses and awards – evaluation of overall success and rewarding based on relative improvement instead of rewarding for certain achievements, fixed targets
  3. Planning – collaborative continuous activity that is oriented towards actions, no separation between thinkers and doers.
  4. Control – control is performed based on relative metrics compared with market trends/other teams/previous periods instead of comparing deviations between planned and actual results
  5. Resources – resources are provided on demand without upfront planning and budgeting
  6. Adjustments – adjustments are made as reactions to market changes or new demand, instead of agreed planning cycles or hierarchical coordination

p.s. translated from this very interesting book http://www.goodreads.com/book/show/18462862 by http://nielspflaeging.com/

p.p.s. comparing my organization against these principles now to identify next steps for improvements

How do you improve the accuracy of Product Backlog estimates?

Posted on Posted in personal improvement

This time i want to share my thoughts about estimates. You can also read this book to get better insight on this topic – Agile Estimating and Planning by Mike Cohn.

There is one very important thing to keep in mind – estimates of size and duration needs to be separated. It helps to plan releases (schedule) with better prediction.

Very good article about life cycle of product backlog item can be found here.
Following activities from my point of view help to improve product backlog items estimates.

Product Backlog grooming meeting (reference)
It is very useful activity and it helps the Team and Product Owner to prepare for sprint planning meeting better and review/updates estimates of future backlog items. This Team estimation should take place regularly. We have a reserved planned meeting in the middle of each sprint. If changes occur or new product backlog items are available the meeting will take place, if there are no changes the meeting is cancelled to avoid waste of time. So, it depends on the situation and Product Owner together with Scrum Master makes a decision.

Product owner briefly presents product backlog items and the development team asks questions. If the global idea is understood the Team moves towards estimation. Some key points about the estimation techniques for teams.

Estimates are shared
Estimates are not created by a single individual on the team. Agile teams shouldn‘t rely on a single expert estimates, estimates are best derived collaboratively by the team, which includes those who will do the work. There are at least two reasons for that: First, we tend not to know specifically who will perform a task; Second, even if one team member estimates size as N story points other team member can remember some fact (problems, changes or something else) from previous sprints which was forgotten by this team member and estimate might be increased or reduced.

Deriving an Estimate
Analogy – estimates can be made by analogy. The Team can say: „This story is a little bigger than that story“. When estimating by analogy, the estimator compares the story being estimated with one or more other stories. It is much easier to estimate relative size rather than absolute size. Do not mix this approach with comparing to a single baseline; it is about comparing one story with another.
Disaggregation – split large stories or features into smaller and easier-to-estimate pieces.

Planning poker
It helps to improve estimates because of three reasons:

  • Planning poker brings together multiple expert opinions to do the estimating
  • Dialogue ensures that all opinions are taken into consideration while making an estimate and opinions are justified
  • Group discussion helps to pin point important things

After the size of product backlog items is estimated Product Owner can prioritize product backlog items later and re-schedule the release if necessary according the team‘s velocity or take other corrective actions.

Sprint planning and Daily Stand-up meetings
This is another level of agile planning which adds another level of precision. The Teams details their estimates of “groomed” product backlog items. You can read more about sprint planning meeting here.

If sprint planning session or results of the sprint identify that size of selected backlog items is different, Product Owner with the Team can review product backlog and make corrective actions: adjust velocity, change schedule, change scope or other.

The daily plan is the most precise, since each team member express commitments to complete (or make progress on) a task during a day. Tasks estimates are adjusted and reviewed every day by the Team.

Different planning levels
Estimates accuracy is improved due to different levels of planning – the release, the sprint and the current day. Such way of planning helps the Team views the project from different perspectives.

The iteration plan helps completing the highly coordinated work of a cross-functional team within short iteration. And the release plan helps the team to keep focus on more distant goals, since only short-term goals may be inconsistent with the desired long-term result.

Why does estimates accuracy matter at all?
People always want to be correct. They feel uncomfortable when are wrong and this happens due to different reasons: personal responsibility, team image on a company level, loose of trust from product owner/scrum master and so on. Motivation will reduce in general and it might lead to not desired results in a long run. But as i noticed the following thing happens first – inaccuracy will result in the team taking on too little or too much, both of which create inefficient story progress through the work queue. And as the result product owner will not be able to predict releases and what features can be expected.
Scrum Master must make sure that estimates are accurate and track the performance of the team.

Practical guidelines to improve estimates

  • Involve the whole team
  • Plan at different levels
  • Separate estimates of size and duration
  • Re-plan often
  • Track and communication progress
  • Learn and adapt
  • Plan features of the right size
  • Base estimates and plans on facts

„Planning is everything. Plans are nothing. “
Field Marshal Helmuth Graf von Moltke