Category Archives: How-To Apply Agile

Practical or step-by-step advice and descriptions on how to do various agile practices.

De-matrixed Teams

Many large organizations currently operate by creating project teams of people who formally report into other parts of the organization. This matrixed organization is meant to allow people to develop centers of excellence around a specialization and at the same time to implement a system of checks and balances. However, this type of organization also often encourages sub-optimal behavior by narrow performance measures and incentives (narrow to the area of specialization).

Consider using de-matrixed teams if you are finding that people on your teams are having a hard time collaborating, or if people are refusing to do work outside their area of specialization, or if people are doing really well inside their center of excellence but seem to have real problems making projects succeed.

What is a de-matrixed team? A de-matrixed team is constituted by having all members of the team report to a primary stakeholder of the endeavor. It is still possible, and often wise, to maintain centers of excellence, but team members no longer report into these centers of excellence. Instead, the centers of excellence become a source of support for teams that have specific needs (skills, infrastructure, etc.).


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Collocate the Team

Collocation of the team is used to improve communication efficiency and to allow the team to learn to be more collaborative. Perfect collocation would have all stakeholders and work performers in the same work space (e.g. a large room) during all working hours. This level of collocation is not usually possible, so adjustments are made.

Collocation reduces wastes associated with waiting, movement, and inefficient communication. Collocation increases learning and feedback and assists with team empowerment.

Collocation can present challenges to people used to working on their own. For these people, a careful consideration of how to accommodate their working style is important, but more important is helping them to understand the need for and benefits from collocation. As this understanding grows and as the team starts to produce noticeable results, most people start to enjoy the close working environment.

When perfect collocation is not possible, consider part-time collocation, video conferencing, having a decision-making proxy represent the stakeholders, getting rid of closed offices, moving into open or shared work spaces or collocating part of the team.

I typically hear a great deal of positive feedback from teams that were previously not collocated after they come together in a common space. For example: “I don’t have to spend hours dealing with email anymore – it takes a few seconds to lean over and ask a question and get a response.” “Meetings that used to take half an hour to organize on people’s calendars now happen spontaneously.” “I can work much more efficiently because the people who I need to collaborate with are right there. No more emails, phone calls, scheduling, and pestering.”


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Brief Note About Types of Backlog Items

In very broad strokes, there seem to be three categories into which backlog items can be put:

1. End Results – new functionality or capability that provides direct value to stakeholders.

2. Infrastructure Investment – work that is done to support the creation or delivery of end results but which does not directly provide value.

3. Debt Reduction – work that is done to eliminate barries to the creation of end results.

There are also some types of items that (typically) are not put on backlogs:

– Ongoing Tasks – tasks that are repeated on a regular basis.

– Constraints – descriptions of the qualities of the end results.

– Milestones – events or dates that define the transition from one state to another in an endeavor.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Self-Steering Team

Team self-steering is accomplished through a structured meeting that is used with regularity and several times or many times during an iteration. This type of meeting is used in order for the team to have a structured method of sharing critical information. Team self-steering is often done with a meeting called the “daily scrum”.

The team self-steering meeting involves each team member answering the following questions:
1.What work have you completed since the last meeting?
2.What work do you commit to complete before the next meeting?
3.What barriers are you encountering that are hindering your work or the team?

Generally, the answers to these questions should be kept brief and concrete. For example, in reporting work completed, the report should name tasks that are completed. Some teams who are using an information radiator for their task tracking will physically manipulate the tasks in some way to indicate they are complete. Team members must avoid getting into details during this meeting. It is not a working meeting where any decisions are made or work performed. Even discussion among team members should be deferred to after the team self-steering meeting is complete. A future entry will detail some of the types of barriers that teams typically come across.

One member of the team is specially empowered to track and eliminate the barriers. In the Scrum methodology, this person is called the Scrum Master. This person must have a pro-active and independent personality and have access to the rest of the stakeholders. The person eliminating barriers should remain the same over the course of an endeavor if possible. Every barrier mentioned in a team self-steering meeting should be resolved before the next meeting if possible. If that is impossible, the unresolved barriers are reported to the team and the team decides for itself how to work around the barrier.

As a rule of thumb, this meeting occurs every day at the same time of day. With a team of about eight people, the meeting should take less than fifteen minutes. Stakeholders who are not committing to perform work may observe the team self-steering meeting, but may not otherwise participate.

Some teams may be in a situation where they have people filling roles as managers, project managers, team leads or administrative assistants. All these roles can be integrated into a self-steering team. The key to doing this is that all team members must be willing to move beyond the strict definition of their role, and participate with equal responsibility for delivering results. For some people, moving outside of a defined role is very uncomfortable, or undesireable. These people may become effective team members with careful coaching.

In general, teams that are very new to self-steering benefit from external coaching that provides insight into teamwork, organizational culture, and personal development. All three disciplines are necessary components of creating a high-performance self-steering team.

The team self-steering meeting amplifies learning and feedback, enables responding to change, helps empower the team, emphasizes individuals and interactions as well as valuable results. This practice is critical to agile work.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Does Agile Software Development do away with Business Analysts?

I’ve been exploring career directions – and I must admit, this question has haunted me for a while. Fearing the answer to be “yes”, I forged ahead, wading through blogs, and meeting with colleagues to find out how they work.

My conclusion: Agile Software Development transforms the role of the Business Analyst.

But this is not surprising – one of the main things that happens when working Agile is a realignment of responsibility with accountability. Customers become responsible to state and prioritize their requirements – and Agile processes hold them accountable for these things. Development teams become wholly responsible for delivering the required functionality – and are held accountable for its quality.

The Business Analyst may find herself floating between these two responsibilities. She must navigate this territory with care – our old way of working often meant taking on accountability from these two groups, a step backward when working Agile. I believe that the BA can become a facilitator – enabling Customers and or Developers to get their jobs done. In some organizations, this role is called “Agile Coach”, and may be played by a BA, a Developer or anyone passionate about enabling the work of the team. While not every team needs a coach, it can be an important role – particularly when newly adopting Agile.

There is a balancing act required to do this… my blog covers a few scenarios derived from discussions with my Toronto colleagues.

A BA not interested in coaching could also retrain as a Developer or move into the Customer camp as a Product Owner or Product Manager. Fear not, there are still many ways to help build great software!


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Adaptive Planning – Using a Backlog of Work

In order to respond to change, plans must be made so that they can be adjusted… and then they must be changed! The agile approach to this is to use adaptive planning with a backlog of work packages or tasks.

In order to create this backlog, an overall result or goal is divided up into work packages. For example, a large company may divide its work into projects where each project becomes a work package. On a smaller level, each project may be divided into work packages, each of which represents some value to the overall project goal (note, this is different from a traditional project work breakdown structure). A third example is in the creation of a book, each chapter may be a separate work package. A work backlog can contain anything that stakeholders consider even remotely relevant to their goals for this endeavor.

Next, work packages are prioritized and listed in strict decreasing priority in a backlog. In this backlog, no two packages have the same priority. Ideally, a single person is responsible for maintaining this backlog and determining the priority of work packages. Collective maintenance of this backlog can be a source of much extra work and even conflict. The person responsible for maintaining the backlog must be trusted to take all the stakeholders’ interests and produce a reasonable priority list.

Each iteration, the team collaborates with the stakeholders to choose some number of work packages to work on and complete. If the team does not think it can complete a work package in a single iteration, it should be broken into smaller packages (remember that iteration length is not flexible!). The team is responsible for committing to the work so they have the final say on how much work they can accomplish during an iteration. No other stakeholders should pressure the team to commit to more.

Inside each iteration, the team breaks the work packages into smaller tasks and prioritizes them. Based somewhat on task priority, individuals in the team choose tasks to accomplish and work on them. It is very important for team empowerment that tasks are neither defined nor assigned by people outside the team.

At the end of each iteration, the work accomplished is demonstrated to the stakeholders. Based on these demonstrations and the lessons learned by the team, the remaining work packages are re-prioritized. Packages in the backlog can be added, removed or changed at any time, but the team’s work can only be adjusted between iterations.

Using adaptive planning with a backlog in combination with iterative and incremental delivery enables the principle of responding to change. It is also a method to improve team empowerment and amplify learning.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Doctor, it hurts when I do this…

Patient: Doctor, it hurts when I do this…

Doctor: Then stop doing it…

A wonderful definition of insanity is “doing the same thing repeatedly, and expecting different results.” Yet, for some strange reason, we persist in using methods that are not working. On several projects at a past employer, I was hearing reports of our corporate-branded custom methodology resulting in late delivery, incorrect delivery, and reduced features, etc. The argument given was always “this extraneous factor happened,” or “the customer kept changing their minds,” or “the customer wasn’t implementing the methodology properly.”

What was the solution? Why, to do the same thing again, only harder! This I hear from many of my colleagues quite frequently. When all is lost, and the methodology is failing, cling more heavily to its rules and structures. Now sometimes this is valid. If, in fact, the methodology is being poorly implemented, and if the methodology is supportive of the environment and culture and circumstance of the project, then by all means, tighten up the implementation. Sadly, however, seldom is a proper analysis done of the fitness of the methodology to the needs of the project.

One of the very nice things about Scrum, for example, is that it is a short-cycle iterative feedback system. It is not a large methodology with lots of process. In a sense, it is a process for uncovering the work that needs doing, and for structuring that work in a highly compartmentalized way. Because of this, it is often quite resilient to external factors. Also, Scrum assumes that outward conditions will change, and assumes further that many of these changes are entirely out of the project’s control. Therefore Scrum is organized to find these externals irrelevant to its measures of success. It’s classic lateral thinking.

Why mention the above? Because the most common failure of a methodology is its inability to handle fundamental change. It requires a certain number of assumptions. If these assumptions change, then the whole project needs to be re-conceived. If you have a project lifecycle that lasts about 2 years, this is a very expensive re-conception. In this context, my above paraphrase could be re-stated to: “Insanity is doing the same thing, in a different context, and expecting the same results.”

With Scrum and other empirical processes, you re-formulate the project on a cyclical basis (say, a month). Thus, all new information can be assumed for the next cycle safely, and everyone is secure in the knowledge that all things can be re-examined next cycle. A problem is turned into a strength.

I’m not saying that Scrum can’t be misapplied, or that people can’t get into trouble there… but the fundamentals of Scrum and empirical processes are such that, if reasonably applied, you shouldn’t need to bang your head into the wall month after month. After all, in the end, if it’s that bad, it’s much cheaper to cancel a scrum project than a traditional plan-based project, because you will tend to know sooner that it needs to be cancelled.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

About People, Tools and Processes

Experienced, smart individuals who work together effectively will always perform better than junior untalented people thrown together at random. The experienced effective group will build its own tools and create its own processes. The random junior group will be unable to effectively utilize tools given to them, nor will they be able to effectively follow a process.

When a team needs improvement, don’t impose a process or throw tools at them. Instead, concentrate on improving the team and the individuals within it. Technical, personal and team training and coaching will always be time and money well-spent. Spending money on processes and tools before an excellent team is in place can be very risky and wasteful.

Individualism and competition have no place in an agile work environment. Instead, the agile environment supports and fosters teamwork, collaboration and consultation. In turn, teamwork, collaboration and consultation depend on trust and truthfulness.  “Truthfulness is the foundation of all human virtues.”

Nevertheless, processes and tools still have some importance. Great people with a great flexible process and great flexible tools will be hyper-productive. A junior group may need training on tools that will help them be more productive. Just be sure to never let processes and tools get in the way of the team.

In many ways, improving people is a sufficient practice for agile work. All the other principles, disciplines and practices would eventually arise out of this one practice. However, the depth of individual and group improvement needed for this practice to stand on its own is very great. Therefore we make the other principles, disciplines and practices explicit.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Iterative Delivery

Work can often be divided up so that the smaller pieces are valuable on their own. By dividing work this way, a team can deliver value incrementally. The team can choose a short period of time called an iteration and select a small amount of work to complete in that time. This work should be valuable on its own. For example, if a team is building something, then at the end of each iteration whatever is built is usable as it is. This means that each iteration includes all the planning and design as well as construction or creation necessary to deliver a final product or result.

For example, a volunteer group may desire to attract new members. A non-agile approach would have the group plan their membership campaign completely before actually executing on it. An agile approach using iterative delivery would have the group plan a small piece of work that will attract some small number of new members, execute it, and then start a new iteration. One iteration may cover the creation of and delivery of a door-to-door flyer in a neighborhood. Another iteration may cover the design, creation and publishing of a small advertisement in a local newspaper. Each iteration includes all the steps necessary to produce a furthering of the group’s goal of attracting new members.

In a business environment, iterative delivery allows for a much faster return on investment. The following diagram compares delivering value iteratively with a non-agile project delivery where results are delivered only at the end of the project:

Iteration Value Delivery

One can see clearly from the diagrams that the non-agile delivery of value at the end of a project is also extremely risk prone and suseptible to change. If the project is cancelled just before it delivers, then a fairly substantial amount of effort is wasted. In the agile iterative delivery situation, an endeavor can be cancelled at almost any time and it is likely that substantial value has already been delivered.

Even if the work cannot actually be delivered incrementally, it almost always can be divided in a way so that it can be inspected in stages. Either method of dividing work allows us to do the work in iterations.

Iterations are fixed and consistent units of time during which work is performed and between which planning, inspection and adjustment is done. The empowered team will decide on the length of iterations for their work. As a rule of thumb iterations should be shorter than the horizon of predictability. Generally, iterations should never be longer than one month, no matter what the endeavor.

At the end of each iteration, a demonstration of the work completed is given to the stakeholders in order to amplify learning and feedback. Between iterations, the stakeholders collaborate with the team to prioritize the remaining work and choose what will be worked on during the next iteration. During the iteration, the stakeholders need to be accessible for questions and clarifications.

Iterative and incremental delivery is used to allow for the early discovery and correction of mistakes and the incorporation of learning and feedback while at the same time delivering value early.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What To Do With the Horizon of Predictability

In a previous entry about constant change, the idea of a horizon of predictability was introduced. This concept, along with the agile discipline of amplifying learning, suggest a strategy for addressing problems in a project.

Continue reading What To Do With the Horizon of Predictability


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Readiness – When Can Your Organization Adopt Agile?

I’ve come up with a short quiz about agile readiness. It has never been tested anywhere. Rather, it represents my observations about what conditions have been in place in organizations where agile has taken root and flourished vs. places where attempts at agile have failed.

Continue reading Agile Readiness – When Can Your Organization Adopt Agile?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Can dying plan-based projects be recussitated?

We’ve all seen this. A one-year project in its 13th month, and the Project Manager has been reporting 80% of the tasks at 90% and has been doing so for the last 120 days. There’s no end in sight, and the customer is leaking cash every day the product fails to go into production. What can be done? Agile project management principles can help this all-too-frequent scenario.

Continue reading Can dying plan-based projects be recussitated?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Index Cards as an Agile Work Tool

Index cards are an excellent tool to use to optimize communication. There are two primary types of use for index cards.

Continue reading Index Cards as an Agile Work Tool


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Stealth Methodology Adoption

This link was seen on a scrum-toronto list, referring to an e-book called Stealth Methodology Adoption. The title is brilliant, and reflects, in my view, a significant means of adoption of Agile technologies at this point in the maturity of this market.

Continue reading Stealth Methodology Adoption


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Kanban System Design® (KMP I)
Toronto
C$1695.00
Mar 26
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Mar 26
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1595.00
Mar 28
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
Apr 2
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Apr 5
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Apr 9
2019
Details
Professional Scrum Master® (PSM I)
Regina
C$1600.00
Apr 11
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Apr 12
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Apr 12
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Apr 13
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Apr 13
2019
Details
Professional Scrum Master® (PSM I)
Mississauga
C$1525.00
Apr 15
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Apr 16
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Apr 24
2019
Details
Kanban System Design® (KMP I)
Ottawa
C$1440.75
Apr 24
2019
Details
Facilitation Skills for the Agile Workplace®
Toronto
C$1350.00
May 6
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
May 7
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
May 8
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
May 14
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
May 15
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jun 4
2019
Details
Certified Agile Leadership® (CAL 1)
Toronto
C$2200.00
Jun 10
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jun 11
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Jun 11
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jun 19
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jun 20
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 4
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Jul 4
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jul 11
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 16
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jul 31
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 31
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1355.75
Aug 1
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Aug 13
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Aug 21
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Sep 11
2019
Details
Coach Skills for the Agile Workplace®
Toronto
C$2018.00
Sep 16
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Sep 17
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Sep 17
2019
Details