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.

You might be interested in these related posts:

1. You are not doing SCRUM if you don't have a ScrumMaster
2. Who benefits from the traditional consulting approach?
3. Top People in the Agile Business Intelligence and Agile Data Warehousing World

Last week, I attended the breakfast conference presented in Montreal by Ken Schwaber.

As always, Ken gave a great presentation focusing on the “definition of done” in Scrum and the impact of incorrectly defining what done really means.

As I was listening to the presentation, I looked outside the window overseeing René-Levesque boulevard and noticed an asphalt truck and city workers filling a pothole – then it hit me… As interesting and valuable Ken’s presentation was, we need a systemic approach if we want Scrum to succeed in organizations. Let me explain…

Nobody likes to drive on a street with potholes. So what do cities do? Obviously, they fix them! If you live in Montreal, you realize that every year, the city fills thousands of potholes in an attempt to keep their streets in a good driving conditions but no matter how much efforts (and money) the city invests, the potholes keep appearing.

Isn’t this like implementing Scrum within an organization?

As attendees to Ken’s presentation, weren’t we simply like city workers attending an asphalt conference? It is as if an asphalt guru was explaining to us the right mix of tar and rocks to make the most resistant asphalt when in reality, the problem isn’t really with the asphalt itself but with the city’s traffic management approach.

Same goes for Scrum.

The definition of done is critical. The right people in the right roles is important. Dedicated teams members is crucial. But what about the managers in the organization? Are they supporting Scrum? I mean, are they really supporting the use of Scrum within their organization?

Don’t get me wrong. I truly believe doing Scrum the right way is critical but it is not sufficient to be successful. If your managers aren’t on board, you can try to implement as many of the Scrum best practices as you want – including the right definition of “done” – your teams will never reach the highest level of performance they could. Get the managers on board and your Scrum implementation will be greatly improved.

You might be interested in these related posts:

1. Agile Data Warehouse
2. Introduction to Scrum – Shareable Power Point Presentation
3. Secret Revealed! Guaranteed Success for your Agile Transition

For those of us who have been working with Agile for a while, the values, the principles, the approach, the methods and the practices are almost second nature but for those who start to enter the Agile world, the ramp up can be challenging – especially if you are looking at all of this from a management position.

After being asked by a few people “Where can I start if I would like to know more about Agile?”, I decided to put together this short list of reference material. There is also a good discussion happening on LinkedIn.

I am missing anything? Is there material you would recommend to managers?

What is Agile?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. (Agile software development – Wikipedia)

“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).

While each of the agile methods is unique in its specific approach, they all share a common vision and core values (see the Agile Manifesto). They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight (especially compared to traditional waterfall-style processes), and inherently adaptable. As important, they all focus on empowering people to collaborate and make decisions together quickly and effectively. (Agile 101: What is Agile Development? | VersionOne)

Just what is agile software development? In 2001, a group of methodologists got together to agree on a common set of guiding principles around effective software development. Rather than summarize their agreements here, I’ll point you to their “agile manifesto”.

From a pure definition standpoint, agile is a conceptual framework generally centered on iterative and incremental delivery of working software, driven by the customer. The iterative part suggests that we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features. (A Brief Introduction to Agile — Developer.com)

What is Scrum?

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem. (Introduction to Scrum – An Agile Process)

Scrum is an iterative, incremental framework for project management and agile software development. Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.

Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach. (Scrum (development) – Wikipedia)

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. (Scrum Alliance -What Is Scrum?)

The Scrum Roles

Scrum has three roles: Product Owner, ScrumMaster, and Team. (Scrum Alliance -Scrum Roles)

Tips for an Agile Transition

Organizational Impact of an Agile Transition

When development teams adopt agile practices, product management is often caught off guard by the amount of work added to their already overflowing plate. Agile calls for new product management skills and traditional staffing models do not typically accommodate the new product owner role. Given that most product managers are already overworked, how can they manage these new activities to derive more value from software projects and products? (InfoQ: How Product Management Must Change to Enable the Agile Enterprise)

Agile methodologies are helping software organizations stay competitive by delivering products more frequently and with significantly higher quality. Making the switch to agile development also challenges traditional notions of project management, introducing new ways of managing time, cost and scope. Learn how to successfully manage agile projects with the resources below. (Agile White Paper: The Agile Project Manager | VersionOne)

When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of “manager” seems to be missing entirely. “Well I guess we’ll have to just get rid of ‘em all!” wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats. (Scrum Alliance -Manager 2.0: The Role of the Manager in Scrum)

About Agile Coaching

Gartner’s analysts (Thomas Murphy and David Norton) predict that by 2012 “agile development methods will be utilized in 80% of all software development projects”. The authors explain that although Scrum will continue gaining in popularity over the coming years, organizations will not be successful in their transition unless they move toward a team-focused culture (Gartner Predicts 2010: Agile and Cloud Impact Application Development Directions | Analytical-Mind)

In their recently released study “Agile Development: Mainstream Adoption Has Changed Agility“, Forrester reports that “35% of respondents stated that Agile most closely reflects their development process”. The report is based on Forrester’s/Dr. Dobbs Global Developer Technographics Survey, Q3, 2009, which surveyed 1298 application development professionals. (Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility” | Analytical-Mind)

Recommended Blogs

Recommended Books

You might be interested in these related posts:

1. Scrum Role: Scrum Master
2. What is Scrum?
3. Scrum Role: The Scrum Team

In my quest to better define what Agile Leadership is and in an attempt to help managers, leaders, and stakeholders understand which behavior to modify in order to achieve a successful Agile transition within their organization, I broke down the key dimensions associated with an Agile Project team - an upcoming post will present the Agile Leadership dimensions. Based on experience and relying on numerous books and blogs published on the topic, I have extracted seven key dimensions in an attempt to generalize the concept.

My goal is to help teams and organizations going through an Agile transition understand which dimensions to modify to change the status quo. I will define at length and provide reference material in an upcoming post.

Agile Leadership - The Project Team

The Project Team

A project team is a team whose members usually belong to different groups, functions and are assigned to activities for the same project. A team can be divided into sub-teams according to need. Usually project teams are only used for a defined period of time. They are disbanded after the project is deemed complete. Due to the nature of the specific formation and disbandment, project teams are usually in organisations. A team is defined as “an interdependent collection of individuals who work together towards a common goal and who share responsibility for specific outcomes of their organisations”. An additional requirement to the original definition is that “the team is identified as such by those within and outside of the team” – wikipedia

Out of the roles defined in Scrum, the project team is a key area impacted by an Agile transition. Many changes are required in order to take full advantage of the transition – from a motivational and a performance perspective. In this context, the project team encompasses the members of the core project team that are working toward the same end goal, which is to deliver results.

The 7 Dimensions of an Agile Project Team

There are tens of variables that have been identified as key success factors for a successful agile transition. My objective is to group them under 7 dimensions. This does not mean that other dimensions aren’t important or that I offer an exhaustive list. My goal is simply to summarize the success factors under a handful of dimensions.

Autonomy

Autonomy refers to the capacity of a rational individual to make an informed, un-coerced decision – wikipedia

The concept of self-organised team is one of the pillars of Scrum. In his recent book Drive: The Surprising Truth About What Motivates Us, Dan Pink presents the differences between empowerment and autonomy (more on his book in an upcoming post) with such compelling arguments that I felt “autonomy” is a much better description of what we aim to achieve with the implementation of Scrum. As such, the team needs to have the ability to determine the sequence of the tasks to be executed, the assignment of each task, the method used to complete their work and other rules required to allow the team to achieve performance while enjoying their work.

A few questions to assess the Autonomy dimension of the project team:

• Are people on the team able to make decisions themselves and accordingly adapt to changing situations?
• Does the team determine “how” to solve their issues?
• Can the teams select the standards and practices that better allow them to produce the right solution?
• Can the team divide the work as it chooses?
• Do training, holiday, and vacation time get cancelled when the project falls behind schedule?
• Can the team members determine who is on or off the team?
• Does the team maintain a high rate of productivity without being overworked?

Competences

Competence is a standardized requirement for an individual to properly perform a specific job. It encompasses a combination of knowledge, skills and behavior utilized to improve performance. More generally, competence is the state or quality of being adequately or well qualified, having the ability to perform a specific role – wikipedia

As with other expertise, project team members must possess and/or develop certain competences in order to take advantage of the new approach. Although some of the new skills are technical in nature, many are softer interpersonal skills.

A few questions to assess the Competences dimension of the project team:

• Does the product owner possess the right skills and abilities to successfully execute his role?
• Are the employees always in an optimal role (matching the requirements with the capabilities and interest of the individual)?
• Do the team members have the required knowledge and expertise to successfully deliver the expected solution?

Accountability

Accountability is the acknowledgment and assumption of responsibility for actions, products, decisions, and policies including the administration, governance, and implementation within the scope of the role or employment position and encompassing the obligation to report explain and be answerable for resulting consequences – wikipedia

As an Agile team relies on its autonomy to complete its work, the concept of accountability becomes even more critical than it is in a traditional team structure. The lines between the responsibilities of each of the team members become more blurry as tasks and timelines get re-assigned in order to meet the expected results.

A few questions to assess the Accountability dimension of the project team:

• Do the team members clearly understand their responsibilities?
• Are the team members committed to the delivery dates?
• Are all the delivery dates clearly communicated and known by all team members?
• Does the team successfully deliver functional software at the end of each iteration?
• Does the team know its velocity?

Collaboration

Collaboration is a recursive process where two or more people or organizations work together in an intersection of common goals by sharing knowledge, learning and building consensus – wikipedia

Collaboration is a central them in Agile and it is more than two people working side-by-side. In the context of Agile, strong collaboration is a critical quality the needs to be demonstrated by the project team and throughout the duration of the project.

A few questions to assess the Collaboration dimension of the project team:

• Is the business representative an active member of the project team?
• Is it accepted that the detail of both the requirements and the solution will emerge as the project progresses?
• Does the project team accept changing business needs?
• Do team members accept tasks outside their role and responsibility in order to successfully deliver?
• Are developers included in the planning process?
• Are the team members heavily involved in the decision making process?
• Is the product owner willing to discuss trade-offs between scope and schedule?

Communication

Communication is a process of transferring information from one entity to another - wikipedia

Just like collaboration, communication is an elusive concept that is fundamental to the success of the project team.

A few questions to assess the Communication dimension of the project team:

• Are the right tools in place to facilitate the communication process between team members?
• Is a wiki in place to centralize access to key project information?
• Does the team have a collaborative space allocated to them?

Continuous Improvement

Continuous improvement is an ongoing effort to improve products, services or processes. These efforts can seek “incremental” improvement over time or “breakthrough” improvement all at once. Delivery (customer valued) processes are constantly evaluated and improved in the light of their efficiency, effectiveness and flexibility – wikipedia

The empirical nature of Scrum imposes continuous improvement to the project team. In order to implement the process for the team members to learn and develop their skills, certain aspects need to be established up front and improved throughout the project life cycle.

A few questions to assess the Continuous Improvement dimension of the project team:

• Are the team members’ performance periodically evaluated and honestly communicated?
• Are the best practices challenged on a regular basis?
• Does the team use an empirical process to learn and improve their performance?
• Does the team hold retrospection sessions to improve?
• Does the team reserve time to implement improvements?

Processes and Tools

Process typically describes the act of taking something through an established and usually routine set of procedures to convert it from one form to another – wikipedia

A tool, broadly defined, is an entity that interfaces between two or more domains; that facilitates more effective action of one domain upon the other – wikipedia

Finally, to take advantage of the changes an Agile transition brings, the project team needs to use different tools and processes in order to avoid falling back to their old patterns.

A few questions to assess the Processes and Tools dimension of the project team:

• Does the product owner understand that solving 20% of the problem delivers 80% of the value?
• Is the team composed of a group of 5 to 9 people?
• Is the team capable of starting the projects with incomplete requirements?
• Are projects broken down into smaller components?
• Are the iterations time-boxed?
• Are the required processes clearly defined and communicated to all team members?

I am currently working on a more exhaustive questionnaire to help those going through a transition monitor their progress. I hope to share the questionnaire shortly.

You might be interested in these related posts:

1. The 5 Dimensions of Leadership in an Agile Context
2. The Nine Dimensions of Agile Leadership (revisited and improved)
3. Project Charter – Agile Project

“Americans hate their jobs more than ever” … ”Majority of Americans dislike their jobs” …

These are only 2 examples of a quick google search that returned over 44.1 million pages. Try “I hate my job” and the content of the pages returned is also very sad.

I don’t intend to go into socio-psychological analysis in this post but I wonder if something as simple as trusting your employees to do their job properly would actually increase job satisfaction?

For most people, enjoying their job would simply mean doing the same type of work but in a different work setting. Many people have spent years studying to develop their expertise in a specific field that they love. Then, one day, they start working and life becomes miserable – not because they hate what they are doing but because of the way the are treated at work. Once again, I don’t want to go into harassment or this type of treatment. The only point I’m raising is that letting professionals determine the best way for them to complete their work would is such a simple of increasing job satisfaction.

“Yes, but I’m the boss” – you reply.

So what? The fact that you were hired to lead or manage people in achieving a team or departmental objective doesn’t make you the most qualified individual to resolve day-to-day issues.

“Yes, but I’ve done this job before” – you insist.

Once again, so what? The individuals performing the job now bring different skill sets and expertise to the equation and as such are qualified to address their work as they see fit. You may provide guidance or answer your employee’s questions when they come ask for help but not tell them how to do their job.

Put together a community of expertise so people doing similar work can support each other. Provide tools if they need, support your employees in finding the right answers to their problems but don’t tell them how to do it.

There is a small Japanese car-manufacturer that understood that concept a while ago. They are now the largest car manufacturer in the world. Don’t you wonder how they achieved their success?

You might be interested in these related posts:

1. Stop treating me like a grown-up
2. Stuck in a dead-end job…
3. Looking for a challenge? You may be interested in an Agile Organizational Coach Job

For those interested, I’m sharing “Introduction to Scrum“. It is a power point presentation covering the following topics:

• Problems with a traditional approach
• What is Scrum?
• Why use Scrum?
• How does Scrum work?
• The Product Owner
• The Scrum Master
• The Team
• The Product Backlog
• Benefits of using a Product Backlog
• The Sprint Backlog
• The Scrum Cycle
• The Burn Down Chart

You can copy, distribute, and use the content of the presentation in accordance to Creative Commons Attribution 2.5 License.

You might be interested in these related posts:

1. Scrum Artifact: Burn Down Chart
2. What is Scrum?
3. Scrum Role: The Scrum Team

Scrum is an Agile management process that uses an iterative and incremental approach to deliver complex software development projects.

The Scrum Cycle

The three fundamental roles of Scrum are : the Product Owner, the Scrum Master, and the Scrum Team.

The Scrum cycle is divided into five activities to be completed by the Scrum Team in order to meet their commitment to deliver on the work included as part of the sprint backlog.

Define

During the definition phase, the project team (the Scrum Master and the Scrum Team) meets with the Product Owner to determine and agree on the priority of the team for the duration of the sprint. The intent is not to agree on the details during this stage but the high level direction the team will follow. The outcome of the definition stage is to start populating a product backlog.

Plan

Planning consists of selecting the high level items from the product backlog and evaluate the value of the various items as well as the estimated efforts to complete the work. As part of a negotiation process between the Product Owner and the Scrum Team, a subset of the product backlog is selected which is then called the Sprint Backlog.

Build

Much happens during the building phase where the development team members select and execute tasks from the Sprint Backlog until all work is completed and a “product” is ready to present to the Product Owner.

Review

At the end of each sprint, the Scrum Team presents the various items that have been developed during the sprint to the Product Owner. This practice has a few clear benefits in that unless metrics can be demonstrated in the application – not on paper or in theory – and shown to provide the expected information, they are not completed.

Retrospect

The final step of the iteration is the retrospection which has a few objectives where the most important one is to allow the team to reflect on the successes and determines which areas need to be improved prior to entering the next sprint. As such, the team collectively assesses its own performance and determine the best way to adapt in order to successfully achieve its next sprint.

You might be interested in these related posts:

1. Scrum Artifact: Sprint Backlog
2. Scrum Role: The Scrum Team
3. Scrum Artifact: Product Backlog

The Burn Down Chart

Definition

A burn-down chart is a graphical representation that shows the progress made during the development cycle.

The Burn Down Chart can be used to show outstanding work for a release or for a sprint and in both cases, the chart represents the amount of work remaining for the completion of the release or sprint versus time.

How the Burn Down Chart works?

The vertical axis (Y-axis) of the chart presents the work remaining to complete the release or sprint while the horizontal axis (X-axis) represents the time.

Scrum Burn Down Chart

The chart typically presents 2 lines going from the top left section of the chart towards the bottom right.  While the first line presents an estimate of work delivered over time, the second line shows the actual values. As such, the Burn Down Chart is useful for predicting when the work scheduled for the current release or sprint will be completed.

You might be interested in these related posts:

1. Scrum Artifact: Sprint Backlog
2. Scrum Artifact: Product Backlog
3. Introduction to Scrum – Shareable Power Point Presentation

The Scrum Team

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the Scrum Team.

Definition

The Scrum Team is a self-organized group of up-to 7 individuals with no pre-defined roles who work in collaboration to deliver upon their commitments. The Scrum Team is often comprised of cross-functional individuals who work to successfully complete the activities identified as part of the sprint backlog.

What the Scrum Team does

The Scrum Team is responsible for the following activities:

• Following a negotiation with the Product Owner, selects the goal of the sprint;
• Organizes itself and its work;
• Plans and executes the tasks identified during the Sprint Planning Meeting;
• Determines the appropriate methods of delivering on their commitments;
• Presents the resulting work to the Product Owner.

You might be interested in these related posts:

1. Scrum Role: Product Owner
2. Scrum Role: Scrum Master
3. Scrum Artifact: Sprint Backlog

The Scrum Master

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the Team.

Definition

As an Agile Project Manager, the Scrum Master is the person responsible to ensure the adoption and adherence to the Scrum process. With no formal authority over the Team, the Scrum Master facilitates the various activities and maintains the Burn Down Chart.

What the Scrum Master does

As a liaison between the Product Owner and the Team, the Scrum Master is responsible for the following activities:

• Helps the team maintain their productivity by removing barriers and preventing interferences;
• Supports the Product Owner in achieving the project’s goals;
• Facilitates communication between the Product Owner and the Team;
• Updates the Burn Down charts and other artifacts to make team progress visible;
• Organizes and facilitates the key meetings: definition, planning, building, demonstration, and retro-spection.

References:

• Scrum Alliance -Scrum Roles
• Learning Scrum – The ScrumMaster
• The ScrumMaster Role

You might be interested in these related posts:

1. Scrum Role: The Scrum Team
2. Scrum Role: Product Owner
3. Scrum Artifact: Burn Down Chart