Category Archive for: ‘Processes and Tools’

The PATH: a model to facilitate the diagnosis of the Agile maturity level 0

Pyxis created the PATH model to facilitate the diagnosis of the Agile maturity level within a team in order to recommend the appropriate intervention. PATH is:

An intervention approach within the organization;
A model allowing to lessen the impact of an Agile transition.

PATH is an acronym for Process-Added value-Technologies-Human, the 4 dimensions of software development.

Processes: Efficiently deliver value with a simple process adapted to the project’s needs (lowest cost within time).

Added value: Deliver functionalities and maximize their business value (prioritization and flexibility).

Technologies: Deliver quickly and consistently with appropriate engineering practices (sustainable pace and skills development).

Human: Deliver at a sustainable pace and in harmony while promoting team work (collaboration and communication).

In addition to the dimensions, the PATH model introduces 3 influence levels—vision, funnelling and emergence—that, when applied to all 4 dimensions, produces 12 intervention areas.

Vision

The ‘Vision’ level shows the orientation to meet established objectives. This level is generally linked to the strategic vision of the organization. The vision represents the objectives to achieve.

For instance:

Maximization of return on investment:

Connection between the IT group and business units, and globally between all stakeholders
Development of inter-project synergies in order to adopt best practices and pool them
Management of simple and adaptable projects in order to reduce administration fees
Capacity to innovate in order to be equipped with the tools required for the organization to evolve
Capacity to anticipate in order to gain a competitive edge
Greater respect for budget allowance

Maximization of a cooperation and collaboration culture:

Better team organization
Evolution of the strategy and change culture
Adaptation of the leadership model

Performance:

Quick project execution compared to traditional approaches
Quality improvement of software delivered
Establishment of parameters allowing to measure performance
Adaption of the competency model and expertise development
Process implementation to select initiatives

Funnelling

The main objective of the ‘Funnelling’ level is to implement mechanisms promoting collaboration (e.g. communities of practice, wikis, and blogs).

This level:

Allows to implement a communication approach in order to make the vision visible
Allows to make sure the field practices (emergence) are aligned with the objectives established at the ‘Vision’ level

Therefore, funnelling allows the emergence of the best practices arising from development teams as well as the dissemination of these practices to all groups that may benefit from them. Therefore, the ‘Funnelling’ level acts as an information catalyst and aggregate.

Globally, the objective of this level is to ensure reuse of:

Tools
Practices
Experience acquired by stakeholders

Emergence

The ‘Emergence’ level is the level for project teams developing software solutions. It is important to implement new development processes and train team members on how to apply Agile principles.

At this level, transformations imply:

New ways of doing
A behaviour oriented towards collaboration in order to achieve established objectives
The implementation of methods allowing to obtain best results

Posted on: 05-16-2011
Posted in: Agile, Processes and Tools, Transition to Agile

Status reporting in an Agile context – Introducing the SunSet Graph 3

You have implemented Scrum with some of your teams and get the following question – “How do we report project status to management?“.

If your organization is like most organizations, your choices are:

You ask someone (the Scrum Master or the Project Manager) to convert (translate?) the information the team uses into the traditional management reports;
You present the information exactly the same way the team is using it;
You find a way to bridge the new reporting to the old reporting in order to reduce re-work.

If you have selected option #1, this post won’t help you much since there is no way for me to know what the traditional information reporting mechanism is within your organization.

If you selected option #2, you don’t need to read this post since you only need to show the information you already have compiled on its current form.

But if you went with option #3, you’re in luck. Well, kinda. My colleagues Mathieu and Elsa have come up with what they call, the SunSet graph [French] – because of its colorful presentation.

The Sprint Burn Down Chart

At the team level, many Scrum teams rely on the Sprint Burn Down chart. The Burn Down is very useful to present the amount of work remaining within the sprint in light of the time remaining. In addition, the Sprint Burn Down has the benefit of presenting true progress by comparison to a baseline in order to determine the team’s ability to meet the sprint timeline.

The Release Burn Down Chart

At a project level, a Release Burn Down chart can be used and is very useful for managers and people around the project to appreciate project progress as it presents actual progress in light of a project baseline. Just like the sprint burn down, the project burn down is a very visual way to present the amount of work remaining with regards to the amount of time left.

The SunSet Graph

The SunSet graph is a great complement to the other “Scrum” reports and is also geared toward management – although the team also benefits from producing it and having visibility to the information.

Just like the burn down charts, the Sunset graph gives visibility to the progress of the project – what is scheduled to be completed with regards to a baseline taking into consideration the estimated efforts by the team. With the associated product backlog, the sunset graph gives complete visibility to the content of the project. In addition to the Sunset graph, a financial graph can be added to give a one-view perspective of the project to managers interested in following the progress of the project.

The SunSet graph divides the user stories into 3 categories: Optional, Important, Mandatory. In a quick look, managers can easily follow the progress of the team in light of their commitment to deliver the stories based on the team’s velocity. Before the first Sprint, the team plots the number of sprints planned for the project (x-axis), the number of points to be delivered (y-axis), and the forecasted velocity.

At the end of each sprint, the team plots its progress by entering the number of stories completed and by adjusting their velocity based on actual numbers. The SunSet Graph Template can be downloaded.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 6 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 9 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 12 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 15 sprints.

By using a visual presentation of the project progress. It becomes easier for managers to understand at a high level the issues encountered by the team. Managers can then focus on anticipating potential budget excess or non-delivery of mandatory stories as opposed to focusing on the content of the project. In addition the keeping managers informed, the Sunset graph supports the concept of the self-organized team.

Posted on: 12-7-2010
Posted in: Communication and knowledge sharing, Processes and Tools, Tools

A great team building activity, let’s do a budget 3

If you are looking for an activity to increase team synergy in an attempt to develop a high performance team, what choices come to mind? A rally? An adventure race? A week-end away? A parachute jump?

Unless you are my wife, the thought of using a budgeting exercise to build team synergy seems ludicrous, especially when the team is mostly composed of senior software engineers and marketing people!

I knew that for most people, the thought of sitting for two full-days of budget planning would be more terrifying than a visit to their dentist for a root canal. Without fear or hesitation and listening only to my courage, I decided to leverage this important corporate exercise (aka. The Budget) with the goal to create a highly performing cross-functional team.

In line with a post recently published by Mike, I followed very simple guidelines to maximise the impact of the exercise.

Invite people to the exercise

In his book (The Right Use of Power), Peter Block suggests that proceeding by invitations when asking people to participate in an exercise or a meeting is much more powerful than deciding yourself who should (or shouldn’t) be part of the group. Since the cross-functional team I was working with needed to represent each area of the organization and I only wanted one representative from each unit, I asked for volunteers. In traditional organizations, the participants would have been selected based on specific criteria. Instead, I opted to ask for volunteers. This had the dual benefits of increasing active participation during the meeting and helping people buy-in to the results once the exercice was over.

Establish roles and responsibilities

To build a self-organized team, I wanted people to determine what each of the participants contributed to the overall discusion. Coming in to the meeting, each participant knew their role was to represent their community. As such, they needed the authority to make decisions on behalf of their group and have a good understanding of the business assumptions so as to know what could (and couldn’t) be changed in their budget. What is typically called empowerment totally applied in this case.

Establish clear objectives

The group was informed ahead of time of the objective they were to reach “x% operating income for the coming year”. All other variables were left to the group to decide. How each group would reach their own objective and how that fit into a global perspective and their strategy was left entirely to them.

Establish an agenda and ground rules

The agenda for the exercise was clearly established ahead of time in order to support the group in reaching their objectives. In addition to the agenda for the two days meeting, ground rules were established.

(translated from French)

Ground rules

Active participation in the discussions
Pay attention to what others are saying
Be open to constructive feedback (it is not personal)
You can enter and leave the room only when the door is open
Be on time
Accept to step outside your comfort zone
Express yourself (kindly) when you are upset
Have a bit of fun (it is already included in the budget)

I have seen too many sessions being facilitated without any ground rules or a clear agenda which typically leads to bad meetings. Wanting to avoid wasting a great opportunity to build team synergy, I made sure those two items were well taken care of.

Get a skilled facilitator

I took charge of facilitating the meeting. I have a few skills and facilitating meetings is one of them

Conclusion

After two very intense days of work, the cross-functional team was able to reach an agreed upon target. Coming in to the meeting, nobody believed we could establish challenging targets for ourselves and most importantly, no one thought they would take full ownership of the end results once the exercise was over.

Once again, in traditional organizations where budgets are a top-down activity imposed by the CEO down the chain of command, ownership of each unit’s budget is un-heard of. In our case, people agreed that the exercise had High Value with a perfect 5 / 5 (see Utilité below), Return on Time Invested of 4.1 / 5 (see ROTI below), and a fun factor of 3.3 / 5 (see Fun below).

Not bad for an exercise that was originally compared to a visit to the dentist !

Posted on: 11-3-2010
Posted in: Collaboration and teamwork, Leadership, Meetings, Processes and Tools

The world would be a better place without accountants 2

It dawned on me recently that organizations are lead and managed by accountants. Accountants come in many shapes and forms and not every accountant wears brown socks.

I suspect you will disagree with my statement arguing that your CEO isn’t a former accountant or that your CTO didn’t even take a single accounting class in his life and I would agree with you. Not all accountants carry a pocket size calculator.

I personally don’t have many complaints about accounting itself, after all there is value in knowing how much money enters your coffers and how much you had to spend to generate the associated revenue. That makes perfect sense to me. Where I have a problem is when common sense leaves the building to make place for accountant-based logic and the need to book everything against the right account and the use of money within certain time intervals.

Confused? Let me explain.

Let’s take project management [Ah, now you are starting to see a link between accountants and Agile projects]. In many of the organizations I had the pleasure to work with, compliance to project plans was more important than delivering real value to customers. Nobody asked if it made sense to add new features or change the sequence of activities in an attempt to deliver business value to customers faster. People are concerned with compliance to the plan. And where does this need for compliance come from you ask? Accountants.

Before the debit-credit masters come running after me with their red pen, I will confess I used to be one of them (sorry!). I understand the mindset, their perspective of the world and most of all, the need to put things in neatly defined categories – some can be amortized while others can’t – but I digress.

The project timelines are derived from the accounting cycles – the money is allocated for a certain budgeting period instead of true market needs. The phasing and allocation of the resources is driven by the departmental allocated budgets. The profile of the resources assigned to a project is driven by who has the money as opposed to who has the skill set.

Does any of this make sense in a context of business excellence? That’s one of the reasons why I like Scrum with its focus on delivering the highest business value sooner. Scrum isn’t perfect, I know but it forces people to make decision based on business value, not accounting rules.

Scrum is also great a giving visibility the what is really going on within a project as opposed to estimated project completion for cost computation. In heuristic tasks such as software development is it really critical to know that task ABC costed $357? Chances are, you are unlikely to do anything useful with that information. Why wouldn’t you rather determine the cost of an iteration (or a sprint) so you can compare it to the business value delivered. As I stated earlier, there is value in accounting but when everybody starts to behave like an accountant, it is a sure sign that common sense is gone and that the organization is ripe for an Agile makeover.

Posted on: 08-17-2010
Posted in: Agile, Processes and Tools, ROI, Scrum