A Student Documentary Film Project

In January of 2005 I was invited to give a one-hour introduction to Scrum to a college media arts class. The class had one group project: to create a student documentary film on some topic. The instructor and the class used an adaptation of Scrum to manage the work of creating the documentary. Some key features from Agile Work included Self-Steering Team, Iterative Delivery, and Adaptive Planning. The following is one student’s reflections on the project. The student who wrote the following was, during my presentation to the class, acclaimed as the best person to be the Scrum Master.

“The whole documentary process has been an enlightening challenge.

First there was the process to find a consensus on a direction. Possibly the first real challenge as a group. As scrum master there were some great personal challenges. I am not a big fan of teamwork. I see it’s value but I have always worked independently and lived or died by my own efforts. There are huge issues of trust and success when you start with a group dynamic. The trust goes both ways. What if I let the group down because of my health or slower technical skills?? When you work independently you can set your own schedule. Will the pressure of letting down the group be enough to motivate the individuals?

SO the second big learning process for me was to be part of a team.
As scrum master I needed to keep myself focused and everyone on track without being a too pushy. NO one has any real obligation to me or anyone else on the team so setting a manageable pace, problem solving as an individual and as a team was another vital part of the process.
The whole concept of iterations kept things in manageable sections, that was a huge contributor to keeping a manageable goal in site when we were all feeling overwhelmed by the load of all of our courses work. AN interesting observation was that I think there were times when what we were doing in documentary was relatively minor but the fact that we were accountable for it everyday made some people feel overwhelmed. I certainly stand to be corrected but I think because we became such a good team that there was (and still is) a sense of the collective workload.

We all improved our technical skills, me particularly. I still have lots to learn but my confidence level is much higher.

There is a lot of respect shown for everyone’s work. We joke about things but people are mostly very respectful of the time and effort people put into their pieces of the puzzle. There doesn’t seem to be a lot of ego attached individually. We are each willing to recognize each other’s strength’s and weakness without rude or critical.

Overall this has been a positive process that is all about teamwork, individual strengths and respect. Garry [the instructor], you have been terrific about leading from behind! There were many times (and still will be) when we know we have a direction but don’t know how to get on the road exactly. You share your professional experience in such a way that we feel like we went searching for buried treasure and made the map ourselves.

I hope to finish the process and keep the momentum to an exciting finished product.“

Sharon

The project was indeed completed successfully! Other students in the class also provided very positive feedback on the use of Agile Work methods.


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

Reality is Perceived – So What?

Results are necessary to reach a goal. Work is done to produce results and reach a goal. Therefore, any work done that does not produce results that contribute to the goal is wasteful. The degree to which a result of work contributes to the goal is the degree to which that work is valuable. However, since reality is perceived, it means that the stakeholders’ perception of the results is of paramount importance. If a team produces a result that the stakeholders do not find valuable, then at that time, it is not valuable. This is both obvious and subtle. If the stakeholders have an articulated set of values, then it is easier for the team to produce results that satisfy those values. However, it is often the case that stakeholders will also have unarticulated values. These unarticulated values are just as important. Agile Work attempts to use various disciplines and practices to elucidate, draw out and make explicit the values of the stakeholders so that the team can produce results that are satisfactory.


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

Agile Household Management – Update

In a previous entry, I described some problems that we are having in using agile work practices in our household management. We have put up a cork board in our hallway in order to hold our tasks. It’s lovely! It also is really practical. As we complete the tasks, we are taking them down and throwing them away. As might be expected, this very physical closure on tasks is very satisfying. For myself, the visible tasks has greatly improved my awareness of what needs to be done. I find myself checking the board a few times a day at least. It remains to be seen if this will help us become more accurate in our selection of work for an iteration…


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

Scrum Evolution: What’s it all about?

Love it or hate it, the Agile 2005 Conference reviewers thought the paper below was either a major innovation or a gross violation of the principles (dogma) of Scrum. It’s motto is innovate or die and only the paranoid survive in the global economy. Does it show the future of Scrum? Well the paper was accepted for presentation at Agile 2005 and many people have asked for the real bits (all 27 pages) before I chop it down to the required 10 page IEEE paper. It could take you to CMM Level 4 or beyond. Decide for yourself whether this paper should be burned or nailed on a door somewhere!


Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects

Jeff Sutherland, Ph.D.

Certified ScrumMaster Training

Patientkeeper, Inc., Brighton, MA, US

Abstract

Scrum was invented to rapidly drive innovative new product to market. Six month releases used to be a reasonable time from for an enterprise system. Now it is three months for a major new release, one month for upgrades, and one week for maintenance releases. The initial version of the Agile Scrum development process was designed to enhance productivity and reduce time to market for new product. In this paper, one of the inventors of Scrum goes back to Scrum basics, throws out preconceived notions, and designs Advanced Scrum using multiple overlapping Sprints within the same Scrum teams. This methodology delivers increasing application functionality to market at a pace that overwhelms competitors. To capture dominant market share in 2005 requires a metaScrum for release planning, variable length Sprints, overlapping Sprints for a single team, pre-staging Product Backlog, daily Scrum of Scrums meetings, and automation and integration of Product Backlog and Sprint Backlog with real-time reporting. A practical example of Advanced Scrum describes how mobile/wireless product teams implemented Scrum process automation during 2000-2005. Administrative overhead for over 45 enterprise product releases a year was less than 60 seconds a day per developer and less than 10 minutes a day for a Project Manager. While Advanced Scrum is not for the uninitiated, the future of Scrum is still Scrum, just faster, better, and cooler.


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

Lean Construction is Agile

I love Hal Macomber’s blog “Reforming Project Management”. And while he writes from a background of Lean Construction, his posts apply across other domains as well – I find they often resonate with the work I do in Agile software development. His site also includes articles and web conferences, and has an RSS feed so you don’t miss his short, salient posts. Have a look!

Reforming Project Management
Hal Macomber, Project Reformer, explores the evolving theory and practices of lean project delivery


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 Manufacturing References

Agile manufacturing: is the ability to accomplish rapid changeover between the manufacture of different assemblies. Rapid changeover is further defined as the ability to move from the assembly of one product to the assembly of a similar product with a minimum of change in tooling and software. Rapid changeover enables the production of small lot sizes, allowing for `just-in-time’ production.

The link is to a page with a list of links to other pages about agile manufacturing. Lots of good stuff to be found there.


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 Little Something from The Theory of Constraints

The Theory of Constraints or (ToC)[Google] is introduced in the book “The Goal“>The Goal” by Eli Goldratt. At its most basic level, the theory of constraints posits that there is only one thing right now preventing your team from going faster. It is the weakest/slowest link in a process or procedure.

How do you find that one thing? There are various possibilities depending on the sort of work environment. One way, that is appropriate to a manufacturing-like process is to identify the Work in Process (WIP) pileup. If you are working in a more human-skills based process, then ask “if you can only hire one skill set, what would it be?”

In an agile process framework like Scrum, there is constant discovery of the constraints (although possibly not the one specific constraint that is slowing the overall process). This discovery is encouraged by the Scrum Master and is exposed by team members as they participate in their daily “scrum” status meeting. An important feature of this meeting is that the team members identify any barriers to the performance of their work. The Scrum Master is then responsible for removing the barriers that are identified.

In organizations that are very paper-documentation oriented, often approval gates are one of the worst constraints in a process. Those who must approve the team’s movement to the next step must receive the documentation they need, then find the time to read it, then find the time to formulate their decision, and then find the time to communicate it to the team. I have been in environments where this can take a few months (I’m sure some organizations are worse, and many are better than this). During this time, the team is essentially idle.

Another typical problem exists in organizations that have gone through several rounds of layoffs in a short time period. In this situation, often the constraint is due to an unbalanced skill distribution. The organization may have very few people with a specific critical skill. The only way to remove the constraint (and speed up) is to add more people with the skill either by hiring or by training.

In general, because of their short iterations, and the resulting amplification of learning, agile teams tend to expose many constraints in the organizational environment. This can be a cause of backlash against the agile team.


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

Scrum and its Relationship to Other Management Techniques

(On relationships of Scrum,TOC, BPR, Systems’ Thinking, Knowledge Management, TQM, Complexity, Manufacturing, New Product Development, etc.)

Although there are great synergies between TOC and Scrum, there are also vast differences. Both provide patterns to resolve systemic problems akin to those described in Systems’ Thinking by Senge, but TOC resolves systemic problems that are more akin to process improvement ala TQM, rather than complete overhauls as in BPR, which I argue, is closer to what Scrum does – it reengineers the process from scratch, by implementing high performance patterns altogether.

For the most part, TOC, and The Goal, assume a somewhat repeatable business process, where the process of removing constraints, exploiting constraints, finding new ones, etc.; is an ongoing process in a somewhat stable, repeatable process.

Scrum, on the other hand, generalizes this technique in the absence of a repeatable process, it simply removes *any* constraints constantly, with no assurance that the constraints removed will remain so the next day, and that the particular constraint optimized
“has been removed”, and that we can move on to new ones at that point. It is usually the case, however.

Another important difference is that a Scrum team is already an organizational structure that avoids process anti-patterns like handoffs, iteration and re-work (among different organizational structures, between an “analysis” team and a “design team” for example, or between an organizational structure building component A, communicating with another one building component B, in a Conway’s Law configuration i.e. where Organization Follows Architecture.

In that sense, a Scrum team is a true “Case Team”, as termed in Michael Hammer’s BPR, i.e. an organization structure that is *completely responsible* for the success of a process or project, where the ScrumMaster is the “Case Manager* ala Hammer, that responds to the Product Owner.

From the Knowledge Management perspective, TOC optimizes the process and therefore, more knowledge of the processes themselves are more valued, while in the Scrum (Case Team) perspective, the individual contributor’s knowledge is more valued.

On the other, and to make things slightly more complicated, Scrum sits atop a number of processes, that as more applications of the same kind are built, tend to be more repeatable, like configuration management, testing of certain components, vertical slice development or new applications on top of reusable architectural services.

The interesting thing to note, is that in Scrum, smaller reusable processes develop underneath as a base of knowledge but they don’t drive development, while the Scrum process, acts as a “work generator/work management” “process envelope” (a superprocess, or meta-process, if you prefer), that drives the work. (In Complexity terms, it is the Maxwell Demon that provides the autocatalytic cycles to drive self-organization, ala Kaufman’s “Origins of Order”.

Curiously, manufacturing is turning more and more to the original BPR patterns to build things. However, New Product Development always requires one meta-level more of work organization to handle the variability of “building something new every time”. In software development this difference evolves into a more continuum spectrum. The first application in a domain is New Product development, but as new ones get added, only a percentage is New Product development, the other percentage is more like manufacturing, and therefore more repeatable.

But don’t worry – no one needs to understand all the above gibberish for Scrum to work. On the other hand, it is nice to understand these things to properly understand Scrum in the context of other management techniques,

– Mike Beedle


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

Agile Household Management – Update

My wife and I have been doing weekly iterations to deal with our household management stuff. As we go along, we are definitely getting through the high-priority items on our household backlog. Along the way, we have encountered a couple of glitches.

1. We missed doing our weekly planning meeting one week. Basically, it was a really busy weekend with way too much stuff going on, both expected and unexpected. We simply failed to remember to do our planning meeting until it was too late to fit it in.

2. Most weeks we miss a number of items that we have selected to complete that week. It can be anywhere from 10% to 70% of the total number of tasks. Usually we get the “larger” tasks done and it is just smaller stuff that we miss.

3. I don’t have nearly the same visibility into the work as my wife does. I travel and am away from home four days a week. As a result, I don’t get to see the state of the house or participate in daily planning except for the three days that I am home.

So, we’ve discussed these things and decided that one thing that will help is to create an information radiator. We will be putting up our weekly selection of tasks on yellow sticky notes on a prominent wall in the hallway between our bedrooms and the rest of the house. The location is a compromise between visibility and privacy. We don’t want the tasks to be in a public portion of the house.

We hope that having the tasks up will allow me to be a little more conscious of the work that needs to be done. As well, it will be a frequent reminder of what is left to accomplish. I hope that this will be a fairly easy and valuable addition to our agile household management process.


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
Advanced Certified ScrumMaster® (A-CSM) [Guided Mentorship]
Online
C$1599.00
Jul 10
2020
Details
Real Agility Series Workshop: How Agility Helps Overcome Bias in the Workplace
Online
C$45.00
Jul 14
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online from Toronto
C$1595.00
Jul 21
2020
Details
Kanban System Design® (KMP I) [Virtual Learning]
Online
C$1795.00
Jul 21
2020
Details
ICAgile® Certified Professional (ICP) [Virtual Learning]
Online
C$1350.00
Jul 23
2020
Details
Certified Scrum Product Owner® (CSPO) [Virtual Learning]
Online from Toronto
C$1795.00
Jul 23
2020
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Jul 24
2020
Details
Team Kanban Practitioner® (TKP)
Online
C$1195.00
Jul 25
2020
Details
Professional Scrum Master® (PSM I) [Virtual Learning]
Online
C$1525.00
Jul 28
2020
Details
Kanban Systems Improvement® (KMP II) [Virtual Learning]
Online
C$1795.00
Jul 28
2020
Details
Real Agility Series Workshop: Cognitive Biases That Can Undermine Your Agile Transformation
Online
C$45.00
Jul 28
2020
Details
Advanced Certified ScrumMaster® (A-CSM) [1-Day Accelerated]
Online
C$1595.00
Jul 29
2020
Details
Team Kanban Practitioner® (TKP) [Virtual Learning]
Online
C$1015.75
Aug 10
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1355.75
Aug 11
2020
Details
Licensed Scrum Master Product Owner® (LSMPO) [Virtual Learning]
Online
C$1695.75
Aug 18
2020
Details
Certified Scrum Product Owner® (CSPO) [Virtual Learning]
Online
C$1525.75
Aug 18
2020
Details
**NEW** Kanban Maturity Model (KMM) {Virtual Learning]
Online
C$2120.75
Aug 24
2020
Details
Professional Scrum Master® (PSM I) [Virtual Learning]
Online
C$1296.25
Aug 25
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1355.75
Aug 25
2020
Details
Advanced Certified ScrumMaster® (A-CSM) [1-Day Accelerated]
Online
C$1355.75
Aug 27
2020
Details
**NEW** Kanban Coaching Practices (KCP) [Virtual Learning]
Online
C$1695.75
Aug 27
2020
Details
**NEW** Advanced Certified Scrum Product Owner® (A-CSPO)
Online
C$1359.15
Aug 28
2020
Details
Coach Skills for the Agile Workplace® (ICP-ACC)
Toronto
C$2020.00
Sep 2
2020
Details
Team Kanban Practitioner® (TKP) [Virtual Learning]
Online
C$1015.75
Sep 24
2020
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$1869.15
Sep 26
2020
Details
Professional Scrum Master® (PSM I) [Virtual Learning]
Online
C$1296.25
Sep 29
2020
Details
Certified Scrum Product Owner® (CSPO) [Virtual Learning]
Online
C$1525.75
Sep 29
2020
Details
Kanban System Design® (KMP I) [Virtual Learning]
Online
C$1525.75
Sep 30
2020
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$1869.15
Oct 3
2020
Details
Licensed Scrum Master Product Owner® (LSMPO) [Virtual Learning]
Online
C$1695.75
Oct 13
2020
Details
Coach Skills for the Agile Workplace® (ICP-ACC)
Toronto
C$2020.00
Nov 2
2020
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$1869.15
Nov 14
2020
Details
Kanban System Design® (KMPI) [Virtual Learning]
Online
C$1525.75
Nov 19
2020
Details
Kanban Systems Improvement® (KMPII) [Virtual Learning]
Online
C$1525.75
Nov 26
2020
Details
Licensed Scrum Master and Product Owner® (LSMPO) [Virtual Learning]
Online
C$1695.75
Dec 1
2020
Details