Who is the right person to fill in the role of the Product Owner? Do they come from marketing, sales or maybe from the IT department? Or maybe it’s that perfect project or product manager? And how does the role of the Product Owner evolve over time? What if it is like a Russian nesting doll that becomes more beautiful and richer the more it grows? Here are 5 Product Owner levels.
It’s rather easy to spot Agile leaders and experts who are all too anxious to point out their knowledge of all things Agile and, more specifically, how some of you out there (not them, of course) are doing things the wrong way. So much about humility and servant leadership. Easier said than done. John Dame and Jeffrey Gedmin article “Six Principles for Developing Humility as a Leader” in the Harvard Business Review discusses six principles for developing humility as a leader, and here’s how they apply in an Agile context.
Agile and Scrum stemmed from software development. Even the vocabulary is rather IT focussed. What about using Agile in a non-software development environment? What are the common characteristics we can leverage? How can we use the concepts of deliveries and goals? How about team and collaboration? Here are 5 techniques we can borrow from Agile and use in any other environment.
Pair programming is difficult to sell. But what if we put a limit to the time people practice pair programming during their normal working day. Here’s an experiment where they limited the pair programming time to 50%, and measured the effects on quality, amount of work completed, employee satisfaction, employee confidence and amount of learning. Here’s the experiment and the results.
Do we need an architect on the team, or do we need the skill set of an architect represented? Many people think an architect is needed as a role. We may disagree with that. But let’s hear that side of the argument. Why is an architect needed? What role do they play? What do we lose if we don’t have one? Here’s a perspective.
Agile requires change in behaviours. We can not change these behaviours unless we are aware of them. We are also unlikely to change them unless we understand why certain behaviours may negatively impact a project’s success. Here are some behaviours, or “anti-patterns,” that are detrimental to the success of your Agile journey.
Let’s say you use planning poker technique to estimate the work. Are estimates and planning poker sessions getting better as your team matures? It not uncommon that instead of getting better, the estimation sessions degrades over time. How to stop that and remain on the improvement journey? Here are a few ideas.
What factors should you consider while hiring a good software developer? Should you look for a particular skill set? What sort of objective success factors would you look for? Should you based you interview on past performance? How about the number of years of experience? Have a look.