Discipline and Agile

Posted on Leave a commentPosted in management

Working agile means you need to be more disciplined, not less! Think it’s one of the main reasons why is it so difficult to implement Scrum in a team (not speaking about whole organization). Here are several aspects:

  • Estimation and planning
    • Iteration planning with clients
    • Daily follow-up with a whole team
    • Iterative reviews of results and further adjustments
  • Team work
    • Definition of Done: list of requirements that all team has to contribute to – qa and capacity testing, documentation, presentations, monitoring.
  • Time boxes
    • Team has to deliver best possible results in a limited time. Requires lot’s of focus and determination
  • Improvements
    • Team is seeking for improvements at the end of each iteration. Normally each two weeks!
  • Transparency
    • Results must be presented to clients or main stakeholders at the end of each iteration

p.s. Stumbled upon the same topic in InfoQ – The Importance of Discipline in Agile

Leave developers alone

Posted on Leave a commentPosted in management

If you are working in a product development company most probably you are doing something wrong if start changes and improvements in a technology departments/teams. Little by little i start to understand that.

Leave developers alone, let them do the work they love and focus instead on the flow and other challenges which require attention and might be missed:

  • Understand and communicate the essence of the product
  • Identify business value and stakeholders’ needs and make sure this is delivered regularly
  • Clarify, negotiate and communicate the important priorities and dates
  • Balance the needs
  • Work effectively with development team(s)
  • Identify, track and address things blocking progress
  • Gather and spread information

Developers can help with all these activities, but most probably they don’t love this type of work. That is why they are not managing the product and don’t want to act as Product Owner or Product Manager.

Before you want to build a feature…

Posted on Leave a commentPosted in quick thoughts

Here is a couple of questions to ask before you want to build a feature.

If we built <feature name>, what measurable business benefit or other positive outcome would be achieved?

If we built <feature>, which roles or user personas would use it, and how often would they use it?

When being a Product Owner what else do you treat as important before you start building something?

Want to learn – explain

Posted on Leave a commentPosted in management, quick thoughts

Want to learn a topic – try to explain it to others. Actually I underestimated this practice or idea I heard from teachers in school and university. But had a chance to prove myself wrong. Several conversations I had recently regarding value structure helped me to understand what things needs to be done and which approach is better to use. Trying to share or explain ideas to others helps to shape up thinking, find answers for grey zones and bring up new ideas from others.

That’s why communities and meetups work – you learn. Took me too long to understand that.

Part 0: When and Why to fire a Scrum Master?

Posted on Leave a commentPosted in management

Scrum Master

“Scrum Master” is a critical role for companies working according to Scrum framework and team success depends a lot on this person. Though a lot of people argue how this role should be implemented and if necessary at all. I think it’s a full-time role. I want to offer an analogy with football manager and show you why Scrum Master’s role is critical and when you should consider firing him.

It seems main reason this role is questioned because there are not so many good Scrum Masters, who really do their work and help team achieve great results. What kind of Scrum Master are you?

Next post on this topic: Part 1: When and Why to Fire a Scrum Master?