Analytical-Mind
A blog offering new paradigms to improve performance and quality of life at work.
  • Home
  • About Me
  • My Virtual Bookshelf
  • Contact Me

Category Archive for: ‘Scrum’

Why did Santa deliver the gifts 2 weeks early this year? 3

Imagine my surprise as we were having dinner last night around 6:40 pm (fettuccine alfredo was on the menu) when I heard a huge “bang” coming from the chimney. The twins, my wife and I quickly got up and went to the living room to discover a dusty Santa Claus putting gifts under the Christmas tree.

“What the heck?”, I said out loud. “Santa, it’s 6:40 pm on December 12th! What are you doing?”, I asked.

“Ho, Ho Ho!” said the old man. “What do you mean? I’m delivering your Christmas gifts. Can’t you see?” said Santa.

“I can clearly see that you are bringing gifts but my question is why on the evening of December 12th? You are 2 weeks early!” I said looking at the various gifts on the floor. All of a sudden I noticed one gift wasn’t even wrapped.

Santa noticed I saw the un-wrapped gift and said “Sorry about this one, there are a few little issues but it should do the job for now anyway – especially considering I am 1 year late!”, he added “… and I apologize since these gifts are for 2009. I’ve really busted my timelines this year”. Whipping his forehead, Santa said, “I don’t have much time to explain but I prepared this document for you to explain everything. I am sure you will find it very useful. My elves spent the last 9 weeks writing the document”.

“They elves wrote a document instead of working on preparing the gifts? Really!”, I said.

Before I could say anything else Santa turned around, moved up the chimney and disappeared. My wife and kids looked at me stuned.

“Daddy, what’s wrong with Santa?” asked Alessia.

“Sweety, daddy doesn’t quit know but I’m sure I will find the answer in the huge manual Santa left us”, I said pointing toward the document.

“Daddy, look! This box is wrapped with toilet paper and it looks like it was open. What’s in there?” asked Giordano. Before I could even speak, he had ripped the paper and opened the gift. “Daddy, these are the pokemon cards I asked for last year. I’m too old to play with these. I don’t need them anymore” said my son angrily.

“Dear Mister. With the greatest magnitude of our sorrows and an unexplainable reason ask for your forgiveness in the event of the delay for the gifts of Christmas and to your honorable family…” I read from the document. ”Honey, this looks like it was translated into bad English. “Do you think Santa outsourced the elves’ work this year?” asked my wife.

Flipping true the book, “It looks like Santa claims that as part of the implicit agreement and based on our list of last year wish list, he delivered what we asked for”, I explained. “As I can see from the documentation, Santa no longer accepts changes in people’s request which is way he delivered what we asked for – even if it is no longer required”, I told my wife.

“Mommy, looks like Santa dropped an envelop on the floor before leaving”, said my daughter as she gave the envelop to my wife.

“Well, I can’t believe it. Santa is asking for a bigger budget and claims he will deliver the remaining gifts around March 14th!”, said my wife clearly upset.

“Wait a minute” I shouted. “It seems to me that Santa should be using Scrum next year. I’ll give him a call on Monday to explain how it could help him deliver on the expectations…”, I concluded before we all went back to a cold dinner.

Posted on: 12-13-2010
Posted in: Scrum

The Role of the Manager in Agile / Scrum – Some of the Best Blog Posts of 2010 3

For those who have been reading this blog for a while, it will come as no surprise that I’m very interested in helping organizations transition to Agile. My contribution is to focus mainly on the managers and leaders, and how they need to modify their leadership style to take advantage of the benefits agility brings to their organization.

Since writing I don’t feel so good – I’m a people manager in an Agile organization, I’ve been on the look-out for good posts on the role of the manager in an agile organization. Below are my 10 favorite articles for 2010.

Drop me a line if you feel I’ve missed something.

  • Changing Agile Roles – The Managers
  • Why Your Boss’s Boss Should Also Go Agile
  • Management 3.0: Being an Agile Manager
  • The Project Leader as a Servant Leader
  • Manager 2.0: The Role of the Manager in Scrum
  • The Project Manager role in Agile/SCRUM
  • What’s a Manager to Do? Management’s Role in Scrum Organizations, Part I, Part II, Part III
  • Cultivate Informal Leadership
Posted on: 12-2-2010
Posted in: Agile, Management and leadership style, Scrum

People managers may be the biggest impediment for increased performance 2

Since the introduction of the PC in the workplace, dramatic performance improvements have been few and far between. In an age where there are more jobs in services than in manufacturing in Canada and where the employees are highly educated, we can wonder why there isn’t any dramatic performance improvements. There certainly isn’t a lack of innovation in organizations, so could it be that something else needs to change?

It is true that the people entering the workforce refuse to be managed like their parents were. They expect to be treated fairly, be given a challenging position where they can learn and apply their skills, and manage their schedule. In this context, standardized work practices and traditional management styles no longer help increase employee performance, it can actually reduce the teams’ performance. Traditional work methods also have the negative impact of driving people away or making it difficult to attract new talent.

Very few people would debate that it takes time to develop highly performing teams and once you have the team on the road to success, you wish to retain your employees. It is these high performing teams that are often the source of innovation within an organization. As long as the organization creates the right environment for people to generate new ideas.

Ever since the 1900′s with Fayol‘s – Plan, Organize, Direct, and Control – managers have been following a traditional approach to people management and we believe that changing the leadership style – to become Agile leaders – is likely to deliver better results and performance.

Why Scrum increases team performance?

As I recently mentioned, traditional managers are used to

  • Assigning work to team members
  • Determining priorities of the tasks
  • Monitoring progress of the activities
  • Making decisions for the team

Whereas Scrum transfers the authority to the self-0rganized team. The underlying concept being that the best solutions will emerge from the team itself.

  • While the manager determines the objective to be reached (the WHAT?), the team determines the means to achieve it (the HOW?)
  • Once the goals is established, management (aka The Product Owner) determines a budget and time lines under which the team will operate
  • Management maintains responsibility to prioritize the activities but without assigning the work
  • Commitments are negotiated between the manager and the team, as opposed to being imposed by the manager – negotiated agreement greatly increases commitment
  • The team is responsible to deliver on its commitment and the Scrum Master is there to support the team in doing so
  • Peer pressure is more effective than authority at getting people to work collaboratively
  • The people closest to the work are in a better position to determine the best way to accomplish their tasks and to potentially introduce innovation in their work methods
  • Frequent inspection and retrospection of the work accomplished creates visibility on the deliverable and prevents faulty results from being delivered
  • The iterative process allows the team to learn from their experience and improve the process
  • People are more motivated when they manage their own work
  • People are more committed when they make their own commitments
  • Teams and individuals are more productive when they are not interrupted
  • Teams are improving when they solve their problems by themselves
  • Productivity is compromised when changes are made to the team composition
  • Face-to-face communication is the most productive way for a team to work and exchange

Seeing how Scrum positively impact productivity and team performance, it becomes critical to determine how the managers must behave to support such progress. As such, managers must:

  • Transfer authority and responsibility to the team so it can do its work adequately
  • Avoid interference and micromanagement
  • Promote collaboration and teamwork
  • Support learning and not systematically penalize failures
  • Review best practices in order to adapt them to changing realities
  • Make adjustments to the facilities so the environment facilitates the execution of Agile projects
  • Adapt the management style to the context of the team

Instead of consequence delivery, managers should focus on making sure the team has learned from their mistakes and have taken appropriate means to fix the issues in the future. In addition, peer pressure is a much stronger motivator and intrinsic motivations are stronger than external motivators.

I believe there is still a lot of value with having managers as long as the new Agile Managers adapt their leadership style and activities to their team. What do you think?

Posted on: 11-29-2010
Posted in: Management and leadership style, Scrum

Feel good Scrum or wishful thinking Agile 7

I sat with one of our customer last week to review the 2011 budget for their Agile initiative. The client had a good start in 2010 with 10 pilot projects adopting Scrum. Not a small accomplishment considering their objective of transitioning over 3,000 people to Agile. The client shared with me that in addition to highlighting potential issues around their projects and increasing the teams’ performance, Scrum helped many of these teams substantially increase employee satisfaction – which is an important factor for employee retention within that organization.

During the meeting, the client explained that now that they had experience with 10 pilot projects, they no longer needed help coaching other project teams in the organization. They recognized the benefits of working with coaches to quickly develop the rights skills and abilities but they could now do it all by themselves.

Let me state it clearly, I believe the end goal of external consultants is to ensure their client can become fully independent and autonomous.

That being said and before I go on with this post I need to say (to be truly candid and transparent) that I have told the client – in person – what you are about to read.

The client’s objective is to successfully complete over 20 Agile projects in 2011 and then 200 in 2012. In itself, that sounds like an aggressive but feasible plan but here the catch: the client believes in magic!

Magic? You be the judge.

The client explained that they had to cut back on the budget for the coming year – which I fully understand – but despite the set back, they were continuing their organizational wide Agile transition. “We have everything we need”, they said.

  • “We are heavily recruiting Agile coaches” – considering the size of our market, it is doubtful they will find all the people they need;
  • “We are putting the heads of the various PMO (project management office) bureaus in charge” – having worked with some of these traditional individuals, it is difficult to see how they could lead an Agile transition;
  • “We have produced a detailed guide to adopting Scrum” – I asked if they remembered Individuals and interactions over processes and tools;
  • “Our people managers are already Agile” – I wondered what that meant;
  • “We have hired a change management expert to document the roll-out process” – Individuals and interactions over processes and tools;
  • “We expect each project team to go out and get the help they need to transition to Agile” – Why not help them?.

“Are you involving the teams and people who will be impacted?”, I asked.

“No need”, they answered. “They only need to execute on the plan we will give them”.

I hope that there is something I am not seeing and I truly hope for them to be successful but as it currently stands, I have serious doubts. Maybe I should offer some magical-Scrum-powder…

Posted on: 11-9-2010
Posted in: Leadership, Scrum, Strategy, Transition to Agile

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

Ken Schwaber and the asphalt truck 1

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.

Posted on: 07-19-2010
Posted in: Management and leadership style, Scrum

Getting Started – Reference Material for Managers Who Wish to Understand Agile and Scrum 6

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

Perhaps, but not necessarily. Pilot projects are commonly done for two reasons: To see if something will work or to learn how to make it work. By now, enough other companies—very likely including some of your competitors—are using agile approaches like Scrum that there is no longer any question of if it works. The real question most organizations face is how to make agile or Scrum work for them. One or more pilot projects can be very helpful in providing those answers. (Transitioning to Agile)

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

Agile methodologies introduce a newer role, typically called the “Agile Coach” that traditional methodologies will not focus on, or even mention. For those who have been working in an agile way for some time, it may seem like a natural complement, yet for those newer to this way of working it raises many questions like, “What’s so important about an Agile Coach: What’s wrong with a Line Manager, or a Team or Technical Lead: Why does Monster.com list 54 positions with this title:” (InfoQ: The Agile Coach, from A to Z)

Market Trends

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

  • VersionOne
  • Leading Agile
  • Mountain Goat Software
  • Noop.nl
  • Analytical-Mind
  • InfoQ

Recommended Books

  • Succeeding with Agile: Software Development Using Scrum, by Mike Cohn
  • Agile Coaching, by Rachel Davies
  • Agile Retrospectives: Making Good Teams Great, by Esther Derby
  • Agile Project Management with Scrum, by Ken Schwaber
  • Managing Agile Projects, by Sanjiv Augustine
  • Collaboration Explained: Facilitation Skills for Software Project Leaders, by Jean Tabaka
  • The Fifth Discipline: The Art & Practice of the Learning Organization, by Peter Senge
  • Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins
  • Drive, by Daniel Pink
  • The Five Dysfunctions of a Team: A Leadership Fable, by Patrick M. Lencioni
  • The Wisdom of Teams: Creating the High-Performance Organization, by Jon R Katzenbach
  • Emotional Intelligence: 10th Anniversary Edition; Why It Can Matter More Than IQ, by Daniel Goleman
  • Coaching for Performance, by John Withmore
Posted on: 06-23-2010
Posted in: Agile, Books, Management, Scrum

The 7 Dimensions of an Agile Project Team 9

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.

Posted on: 03-29-2010
Posted in: Agile, Agile Leadership Model, Leadership, Management, Scrum, Transition to Agile

You don’t believe workers can self-organize. Think again. Even 8 year-old kids can do it! 3

The Experiment

Picture made available by daedriusI attempted a small experiment with my kids a few weeks ago – get them to voluntarily help clean the house. If you have children between 7 and 10 year-old, I’m pretty sure having your kids help with cleaning is nothing short of a nerve-wrecking experience. If you don’t have kids, the process typically goes like this:

  • You – “Timmy, can you please pick up the toys in your room.”
  • Timmy – “Why?”
  • You – “Because your room is a mess and I break my face every morning when I come wake you up.”
  • Timmy – “OK, I’ll clean up.”

30 minutes later, you go see Timmy.

  • You, slightly annoyed – “Timmy, what are you doing?”
  • Timmy, looking up – “I’m building a castle, daddy. You want to play with me?”
  • You – “Yes, I’d like to play with you as soon as I’m done cleaning up. Why didn’t you pick up your toys like I asked you too?”
  • Timmy – “OK, I’ll clean up”

30 minutes later, you go see Timmy

  • … (you can guess the rest)

So, back to my experiment. A few weeks ago, while my wife was grocery shopping I decided to use an adapted version of Scrum. I called my son and his twin sister and told them we would do a little activity. To their enjoyment, they were wondering what I had in mind. They sat next to me at the table while I the took 4 x 6 index cards and on each of them, I wrote a task: pick up the toys, put your clothes in your drawers, empty the garbage cans, bring the recycling to the garage, put the Tupperware away in the drawer, vacuum the floor, etc.

  • My son – “Daddy, why are you writing these down?”
  • Me – “We’ll play a little game.”
  • My daughter – “Can I play too?”
  • Me – “Of course. Here’s how it goes. I wrote 8 cards and each card has a little task. I need you to help me clean up the house while mommy is doing grocery.”
  • The twins – “OK, what do we do with the cards?”
  • Me – “You will each select the cards (the tasks) you would like to do. You then decide in which order you want to do them.”
  • My daughter – “Daddy, some tasks are longer than others. What do we do about that?”.
  • Me – “It’s up to you to decide.”
  • The twins – “It doesn’t matter. We’ll decide which ones we pick.”
  • My son – “Do we get a reward for doing the work?”
  • Me – “Mmmm, good question. I know you like to read. How about I give you tokens for each task? Once you get 50 tokens, I’ll buy the book you asked me.”
  • My son – “OK.”
  • My daughter – “Can I buy a beeds set instead of a book?”
  • Me – “Sure.”
  • The twins – “Can you write how many tokens each task gives on the cards?”
  • Me – “Good thinking! Picking up the toys is 3 tokens, bringing the recycling to the garage is 1 token, …”
  • The kids – “OK, but who picks first?”
  • My son – “Let’s do rock – paper – scissor.”
  • My daughter – “Yes, let’s do rock – paper – scissor.”
  • The twins – “ROCK, PAPER, SCISSOR…”

After determining who would start, they quickly picked the cards and started doing the assigned task. At their own pace, they executed on the cards. Then, something cool happened.

  • My son – “Daddy, can we add a card? We need to water the plants.”
  • Me, laughing – “Of course. Who’s going to take this one?”
  • The twins – “Me, me, me!”
  • Me – “I guess we’ll have to write another card so you are even.”
  • My daughter – “Can I dust the bureau? I saw mommy do it the other day and I’d like to do that.”
  • Me, with a big smile – “OK, if you’d like to do that. I’m OK with this.”

Together, they successfully completed all their tasks. All of their tasks! No fighting, no screaming. That was a “proud moment” :) Imagine when my wife got back home after the grocery…

With the Xmas Holidays and the broken routine, I was pleased to see my kids grabbing the cards by themselves this past Saturday and starting to execute on the routine. “Wow, this self-organization thing really works! Even with kids…”, I told myself.

The Take-Away

If you want people to carry out a task, here are a few suggestions:

  • Describe the task;
  • Let the team self-organize;
  • If the team needs help, you may suggest tools or a process – but do not impose them;
  • Get out of the way;
  • If possible, make it fun;
  • That’s it.
Posted on: 01-18-2010
Posted in: Agile Management, Collaboration and teamwork, Leadership, Management, People Management, Scrum

Scrum daily stand-up meeting. Can you stand-up for something important today? 0

If you are using Scrum and Agile within your organization, you already know about the daily stand-up meeting and the value its brings to the team. Many organizations who have not fully adopted Scrum still find the stand-up meeting to be extremely useful when done properly – but this is not the objective of this blog post.

We have just released a really neat ipod touch app – the _agilely Timer. No, this is not a shameless plug but a way to help people in need. As part of the Agile Tour, Pyxis has released a timer application that allows you to efficiently facilitate daily stand ups, roundtable discussions and manage timeboxes. For only $1.99, this is a great way to help FIAN since all revenues will be donated to this organization that “fights hunger with human rights”.

Go ahead, get this neat app and stand-up for something today.

Buy it now - only $1.99

Buy it now – only $1.99

_agilely Timer to support FIAN.org

_agilely Timer to support FIAN.org

For only $1.99, help fight hunger

For only $1.99, help fight hunger

ipod touch and iphone timer application

ipod touch and iphone timer application

Want to know more, you may be interested in this blog post in French or the English version translated by Google.

Posted on: 10-15-2009
Posted in: Agile, Scrum, Timebox, Tools
Page 1 of 3123»

Popular Posts

  • Agile self-organized teams - is the team self-organized or not?
    01-25-2011
  • Agile transitions are hard. I wonder why people feel the need to control?
    10-5-2010
  • Which stance should I take? The 4 quadrants of Agile Managers
    12-20-2010
  • My Virtual Bookshelf
    01-24-2011
  • What is the job of the president in a self-organized company?
    10-18-2010

Blogroll

  • Agile Gardener – Gardening Agile Knowledge
  • Great Leadership – Opinions and information on leadership and leadership development by Dan McCarthy
  • John Baldoni On: Leadership, Leadership development, Managing people
  • Management 3.0 – Leading Agile Developers, Developing Agile Leaders
  • Management, Development, Complexity, and Me
  • Marshall Goldsmith On: Leadership, Managing people, Coaching
  • Pyxis Technologies
  • Umuntu – It's all about people and humans, anyone at all …
Avatars by Sterling Adventures
Recent Posts
  • Analytical-Mind has moved
    08-10-2011
  • Adapting your leadership style to the maturity level of your self-organizing team
    08-9-2011
  • Agile managers do not act like cowboys
    08-1-2011
  • 12 tips to be a better coach
    06-20-2011
  • Gartner's Enterprise-Class Agile Development Defined
    06-6-2011
Recent Comments
  • links for 2011-08-14 « Dan Creswell’s Linkblog on Adapting your leadership style to the maturity level of your self-organizing team
  • Michael cardus on Analytical-Mind has moved
  • Making The Entire Organization Agile | Pyxis blog on The myths of self-organized teams
  • Making The Entire Organization Agile | Pyxis blog on Yet Another Agile Maturity Model (AMM) – The 5 Levels of Maturity
  • Adapting your leadership style to the maturity level of your self-organizing team | Analytical-Mind on Seven wrong reasons to adopt Agile
About Me

Meta
  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
© 2008-2011 Martin Proulx