Monday, April 20, 2015

Let the team self-organize


I must confess I haven't gone yet too long through the theory of agile, scrum, SAFe and so no. However, after six months playing the role of scrum master I know I want to stick to the agile principle of self-organizing teams as the most powerful tool to come up with "the best architectures, requirements, and designs".

Obviously, this principle may (and probably must!) be constrained by the rules of the organization the team works for; here you can find a good case about this fact, with examples I couldn't agree more with.

However, there may be a risk of excessively narrowing the decision autonomy of the agile teams, specially when it comes to a big company, where they must coexist with the traditional, hierarchical structures in charge of IT infrastructures.

And here comes my recipe: the standards, procedures, methodologies... belong to each technical leader (although they should always be open to a healthy negotiation!). But the way the scrum team complies with them should be just an internal decision, out of reach for external influences.

Frankly speaking, I haven't "cooked" it yet, but promise to keep you updated on the eventual result :)

Sunday, April 19, 2015

Keeping pace with the business team

The PI planning (a.k.a., Release planning) session is a significant ceremony in the Scale Agile Framework (SAFe) that plays a key role as a clutch between the long-term, strategic goals and the short-term, sprint-paced deliveries, providing a framework for the Scrum to prioritize the features that will be released in a medium-term period (usually several months). But probably you already knew this, right? ;)

Well, let me make my case today: that important ceremony might provide you also with a new opportunity to fix/improve one of the most crucial aspects of the scrum development: how to match the pace of the business crew (product owner, business analysts and others) with the production capacity of the developers team.

Software development always occurs once requirements definition is done (remember the DoR?) and definition is clearly a business team's responsability; but software roll-out is usually followed by the monitoring of the clients response, another business team's responsability. These interrelations suggest that you should plan your PI in such a way that definition and monitoring outperforms development.

In other words, during the PI planning you want to ensure the business guys will keep a healthy pace on doing their preparation tasks -business plans, groomings, DoR's...- for the features to come during the new Program Increment... even though the eventual development rhythm goes slower than what  the development team could do!

PS Over time, I hope you and me will find the equation to optimize the resources in both, the business and the technical sides of the Scrum. Any ideas?

Wednesday, April 15, 2015

A rush of adrenaline

I want to devote my first post to one of the most important milestones in the SAFe practice: the PI demo (also known as System demo).

PI stands for Product Increment, and although it clearly relates to each new package of the software that incrementally and steadily keeps making up the application being developed by the scrum team, it also refers to the regular period in which such new packages are released. You can think of it as a super sprint, with its specific planning and wrapping up ceremonies.

In our company we currently stick to a period of a quarter, and last week we could experience the opportunity to share our first Product Increment with the rest of the agile teams involved in our SAFe portfolio. The ceremony was just a kind of rehearsal, previous to the marketing of the application, where the team had to demo the new features developed during the last three months.

I cannot wait for the pilot of our application with clients to kick off, a release scheduled for the next two weeks, but believe me: in the meantime, there are not many rewards to the effort and involvement invested by the team during 5 or 6 sprints than the appreciation of your own colleagues for a well done job.

A major rush of adrenaline!

PS By the way, a very convenient mood for the task to come inmediately after the PI demo: the next PI planning, but this topic deserves its particular post ;)