Notes from agile book …

Posted on Posted in management

I am back from a quite long vacation, for a complete “reload” I didn’t use any high tech stuff. That’s why there was no news from me. Since I had a lot of free time I was reading a number of books, one of them is – “Agile software development with SCRUM” by Ken Schwaber and Mike Beedle. This book covers main agile/scrum concepts in a very good way, but it might look a bit boring for those who already know that. But even despite of that I found some very interesting key points; different phrasing of known things ant etc for myself and decided to share them with you. All this in common helps to structure/renew your knowledge.

Input for new sprint

Key of being hyper productive
It is not only Scrum organization pattern/framework helps to achieve that, but also some everyday practives:

  • Constant component testing
  • Integrations of packages
  • Constant refactoring of selected parts of the system
  • Learning and early adaptation

Product Owner vs Product Manager
Product Manager is only focused on the outside the organization (external communication and etc.) and mainly represents customer. Meanwhile Product Owner is collaborating closely with the Team and is the main decision maker regarding product roadmap.

Product backlog items
Different non-functional issues (a.k.a slow response time and etc.) can be included into product backlog, BUT they need to be elaborated into workable item.
If accurate or reasonable estimate cannot be provided, than a backlog item needs to be re-factored: split, add more details and etc.

Knowledge creation
Explicit knowledge – UML graphs, documents, graphical information ant etc.
Tacit knowledge – based on experience (operational knowledge)
Daily scrum is a good example of knowledge interchange. Please see diagram below – knowledge transformation FROM – TO

SCRUM
SCRUM is empirical and the team can reduce functionality and still meet goals, and management can adjust based on achieved results.
Scrum Master should not solve internal problems; let the team figure that out. (Responsibility is taken away)
Team is interested in product increment, not in time management.
First sprint must produce key piece of functionality and setup effective work environment for new project.
Absence of daily builds is dangerous

Scrum values

  • Commitment
  • Focus
  • Respect
  • Transparency
  • Courage

TOP 10 world companies look like this

  • Built-in stability (creativity)
  • Self-organizing teams
  • Overlapping development phases (requirements are defined while developed)
  • Multi learning – to respond quickly to changes
  • Transfer of learning