Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

SPaMCAST 300 – Vasco Duarte, #NoEstimates

www.spamcast.net

Listwww.spamcast.net

Listen to SPaMCAST 300

Show 300! Show Zero was published on January 7, 2007. 2,738 days later, we feature our interview with Vasco Duarte. We discussed #NoEstimates, which evokes a great deal of passion.  The interview will embraces that passion and we sort through the noise to get to the core of the idea which is highly useful despite all of the controversy. #NoEstimates asks teams, product owners and leaders to rethink how they predict project performance.  Change is hard but Vasco describes a less painful path to predicting delivery.

Vasco’s Bio:

Product manager, scrum master, project manager, director, and Agile coach are only some of the roles that Vasco has taken in software development organizations. That experience has been gained by having worked in the software industry since 1997, and being an Agile practitioner since 2004. Vasco has worked in small, medium and large software organizations as an Agile Coach or leader in Agile adoption. He was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure.

Vasco’s blog can be found at http://SoftwareDevelopmentToday.com

Follow Vasco on Twitter @duarte_vasco

Next

Software Process and Measurement Cast number 301 will feature our essay on technical debt. Technical debt is the work not done or the shortcuts taken when delivering a product. We all take shortcuts, but at what cost?

Upcoming Events

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 


Categories: Process Management

SPaMCAST 300 – Vasco Duarte, #NoEstimates

Software Process and Measurement Cast - Sun, 07/27/2014 - 22:00

Show 300! Show Zero was published on January 7, 2007. 2,738 days later, we feature our interview with Vasco Duarte. We discussed #NoEstimates, which evokes a great deal of passion.  The interview will embraces that passion and we sort through the noise to get to the core of the idea which is highly useful despite all of the controversy. #NoEstimates asks teams, product owners and leaders to rethink how they predict project performance.  Change is hard but Vasco describes a less painful path to predicting delivery.

Vasco’s Bio:

Product manager, scrum master, project manager, director, and Agile coach are only some of the roles that Vasco has taken in software development organizations. That experience has been gained by having worked in the software industry since 1997, and being an Agile practitioner since 2004. Vasco has worked in small, medium and large software organizations as an Agile Coach or leader in Agile adoption. He was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure.

Vasco’s blog can be found at http://SoftwareDevelopmentToday.com

Follow Vasco on Twitter @duarte_vasco

 Next

Software Process and Measurement Cast number 301 will feature our essay on technical debt. Technical debt is the work not done or the shortcuts taken when delivering a product. We all take shortcuts, but at what cost?

Upcoming Events

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

Building A Backlog: Technique Synthesis

 

Putting the parts together!

Putting the parts together!

Hand Drawn Chart Saturday

Techniques for building an initial backlog can be classified by how the conversation between stakeholders and the project team is initiated. Some techniques are focused on asking, other techniques focus on observing, while the third category is all about showing something and getting reactions. Most practitioners blend the best from each of the categories. Here are some examples of the hybrid techniques:

Role Playing Prototype: This technique blends paper prototypes (show) with role-playing (observe) to get users and stakeholders to consider how they might act in an environment that has not been fully designed.

Straw man/JAD: This synthesis seeds a JAD session (ask) with an loose outline of a solution or set of potential solutions that are used to guide the discussion which are at the core of JAD. However, the seeding tactic can inhibit creativity. The technique is less constraining when a set of competing solutions is used as the conversation seed, however developing the range of solutions before the JAD session  increases the cost of the JAD.

Embedding: This techniques puts team member(s) into a department to actually perform the work (observe) alongside actual users and stakeholders. This generally requires the embedded team member to be trained and mentored to intimately see how the work is done. I have seen debrief sessions added to this technique to ensure that participants get a chance to discuss the nuances in the workflow.   As I have noted before, with any observation technique everyone needs to understand what is going on and why. This is not an episode of Undercover Boss.

Combining tactics from different categories of techniques that teams use to develop an initial backlog can fundamentally change the dynamics of the requirements definition session. A group of stakeholders will generally have a diverse range of learning and interaction styles that they favor. Combining backlog building techniques gives the project team a better chance at making a connection. Combining techniques should not be done randomly or an ad-hoc basis. Selecting which techniques to combine has four prerequisites:

  1. Someone with experience and training (perhaps a business analyst).
  2. A knowledge of the user community (knowledge the product owner can provide).
  3. Planning (time and effort).
  4. Involved users and stakeholders (call on the product owner and project sponsor to help with this prerequisite).

Developing an initial backlog is a step to get projects going and moving in the right direction. It is, however, only a first step. Backlogs will evolve. Teams, product owners, users and other stakeholders will gain knowledge and experience as the project move forward that will continually shape and reshape the backlog.


Categories: Process Management

Building A Backlog: Notes on Showing For Gathering Requirements

The evacuation instructions could be a form of paper prototype.

The evacuation instructions could be a form of paper prototype.

The most powerful single technique for generating requirements is showing users and stakeholders something and collecting reactions. There are numerous techniques for developing something to generate feedback, ranging from functional code that could implemented in production at one extreme, to functional prototypes in the middle, to paper prototypes at the end of the scale. Functional code is used to generate feedback to evolve the backlog in Agile projects, however showing techniques are not used as often as they should be to generate the initial requirements backlog. The reason these techniques are not used is the perceived level of effort needed to generate the prototypes or an impetus to begin building the solution immediately.

The power of the showing techniques is based on the theory that many people only know what they want when they see it. The process of generating feedback and requirements is also risk management. A prototype reduces the risk that the project will either build the wrong thing or build the right thing wrong. Functional prototypes also, to an extent, are useful to prove that a solution is at least conceptually feasible (prototypes are generally too small and not fully functional therefore do not truly serve to prove technical feasibility). Paper prototypes address generating requirements and reducing risk but are faster and cheaper to generate because there is no code or code related infrastructure. A very simple example of a paper prototype for a customer relationship management system (CRM) might be set of drawings of screens to show the rough flow of work.  Users to use the paper screens to imagine the process and discuss the flow. In comparison a functional prototype would have mock screen on a computer show system flow but typically without any background functionality.

The first issue with prototypes is that developing them requires time and effort. Project teams are often presented with a goal, a budget and a deadline. In most corporate IT organizations, performance against the project budget is considered a critical measure of progress (and in the longer term, project success). Therefore teams and project/program managers mercilessly manage the budget to improve the possibility of project success. Unless prototyping is built into the budget and the planned approach for the project, there will be pressure to use the less costly, albeit less effective, asking techniques to generate requirements. Teams, sponsors and project managers make a rational choice to manage the budget risk against the possibility of not generating a good enough backlog to get started. However, generating requirements using prototypes is a process that can used to balance requirements and budget risk. The higher the risk of not having a more through early backlog the more important techniques like prototyping will become to mitigate that risk.

The second issue that the use of prototypes face is what I call “starting fever.” In many methods, including Agile, the whole cross-functional project team is assembled to start the project. There are many individuals that don’t believe that gathering requirement is important, therefore unless there is something for them to build or test, they will find other things to do. There are numerous ways to deal with this type of structural slack; here are two extreme cases will illustrate the range. The first solution is to have a subset of the team (like the Three Amigos) generate the initial backlog before kicking the project off. The second solution is have the whole team spend a day as the project kicks off to generate a quick initial backlog and then use the demonstrations at the end of each sprint to continue to flesh out the backlog. I lean towards scenario one or variants in which the other portions of the team work on framing the technical and physical infrastructure.

Another way “starting fever” can be triggered is because of the panic a fixed budget, fixed scope and fixed date project that someone actually said yes to before requirements are known can cause. Before you protest, regardless of how much every developer, tester, BA, project manager or CIO believes in that this an irrational situation they happen ( I see this as the norm in some organizations) and they casue teams to abandon good  practices like prototyping. In the long run project teams have to pick up the pieces when these types of projects had problems. When teams are put under immediate schedule, budget and scope pressure, leaping into action and then creating and firming up a backlog later can look like a great solution. Action is still equated to progress.

Prototyping is an effective tool for driving out requirements that can’t be expressed until they are seen. The backlog building techniques that show the users and stakeholders something to react to also serves to mitigate the risk of building the wrong thing or the right thing wrong. The power of these techniques is offset by the cost and time required to generate prototypes and a fear that unless you are building something the project has started and the due date is at risk.


Categories: Process Management

Marketing scrum vs IT scrum - a report published and presented at agile 2014

Xebia Blog - Fri, 07/25/2014 - 17:49

As we know, Scrum is the perfect framework for IT / software development projects to learn, adapt to change and deliver great software of value, faster.

But is Scrum also usable outside of software development? Can we apply similar or maybe even the same principals in other departments in the enterprise?

Yes, we can! And yes there are differences but there are also a lot of similarities.

We (Remco en Me)  successfully implemented Scrum in the marketing departments of two large companies: The ANWB and ING Bank. Both companies are now using Scrum for the development of new campaigns, their full commercial expressions and even at the product development level. They wanted a faster time to market, more ownership, and greater innovation. How did we approach and realized a transition with those goals in the marketing environment? And what are the results?

So when we are not delivering software but other things, how does Scrum change? Well, a great deal actually. The people working in these other departments are, in general, quite different to those in Software Development (and yes more than you would expect). This means coaches or change agents need to take another approach.

Since the people are different, it is possible to go faster or ‘deeper’ in certain areas. Entrepreneurial skills or ambitions are more present in marketing. This gives a sense of ‘act first apologize later’, taking ownership, a higher drive to succeed, and upfront and willing behavior. Scrumming here means thinking more about business goals and KPIs (how to go from department to scrumteam goals for example). After that the fun begins…

I will be speaking about this topic at agile 2014. A great honor offcourse to be standing there. I will also attende the conference and therefor try to post some updates here.

To read more about this topic you can read my publication about marketing scrum. It has the extensive research paper I publisched about this story. Please feel free to give me comments and questions either about agile 2014 or the paper.

 

Enjoy reading the paper:

Marketing scrum vs IT scrum – two marketing case studies who now ‘act first and apologize later'

 

Quote of the Month July 2014

From the Editor of Methods & Tools - Fri, 07/25/2014 - 08:22
Research has shown that the presumption of selfishness is true for maybe 30% of most populations; another 50% are reliably unselfish, and the remaining 20% could go either way, depending on the context. If a company presumes that the undecided 20% are selfish, you can bet they will be selfish—it’s a self-fulfilling prophecy. But worse, the company will create an environment where the 50% of the people who are unselfish are forced to act selfishly. And losing the energy, commitment, and intelligence of half the workforce is perhaps the biggest ...

Building A Backlog: Notes On Observing For Gathering Requirements

3740422323_12654e3ec0_b

One of my jobs during high school was in a tire manufacturing plant in Memphis, Tennessee. On more than one occasion the hated and dreaded time and motion “guy” showed up to observe how I was doing my job. I never knew what the outcome of the observation was or whether the change to the four page process I performed to sort green tires was due to the observation. The job was never easier after the change. Reflecting on that time (and several industrial classes later) I understand that observation is an important tool for developing an understanding of how work should be done, but is not a tool to be used all the time. Using observation in the right scenarios and then taking steps to plan how you will observe is critical getting value for the effort needed.

Why observe? The simplest and clearest rational for using observation techniques is that users and stakeholders either don’t always know what they want or can’t always express their current needs and foresee their future needs. Therefore a new set of eyes will expose more and different needs. There are four typical reasons for observing should be considered as a tool gather knowledge and requirements.

  1. Physical location is a determinant. Processes and work flow is often affected by the physical location. When the physical layout of the people or machines could strongly affect the solution the team developing the initial backlog should observe the process in action to understand the nuances of flow of work.
  2. When people can’t tell you. Occasionally the process being studied will be so complex that no one is able to coherently describe how it works or how it should work. Even more occasionally asking is met by silence due to lack of trust. In both cases observation is a valid tool to develop an initial backlog.
  3. When interactions are crucial. Complex processes often require a wide range of interactions between people, tool and applications. Interactions, except when they cross the boundary, are difficult to identify unless you see them.
  4. When the output and the process don’t match. When, on occasion, the measured output or the output described by a manager does no match what is possible based on the published process then observing the real process is mandatory.

Once you have decided that you must observe, planning becomes a necessity.

  1. Begin by reviewing the known policies, culture and process of the organization or team being observed. This step helps to ensure that you have a sense of the environment and what you will be seeing.
  2. Decide on how long you will observe. Some processes and process variations need time to be seen. If a process requires a week to complete you will need to observe for at least that amount of time.
  3. Determine how you will record what you see. Trying memorize what you see will result in some information, however you will at least need to take notes. Remember that recording can include taking notes or recording audio and video. The level of detail needed will help determine the method needed.
  4. Finalize the logistics of the observation session before showing up. Office space, network and physical access can suck up huge quantities of time and effort. If you have a week for observation do not spend the first day dealing with administration tasks.
  5. Decide how you will create rapport with the group you are observing. Your presence will cause disruption. You need to find a way of observing with minimal impact to the results and without scaring those you are observing into calling placement firms. I am a fan of transparency; tell people why you observing and what will be done with the data. Where possible I usually involve those that I have observed in an early review of the data collected to elicit more information (hybridization of techniques by combining observing and asking).
  6. Finally do what was planned, but do not be afraid to tweak the plan as needed.

When I was in the tire plant, the time and motion guy would just appear and no one was thrilled. When we saw him coming we followed the proscribed process a bit more carefully, even if it was less effective. Observation can change behavior positively or negatively (Hawthorne effect). Sometimes observation might be the only way to know what is really happening, but without planning the data you gather might be what someone wants you to know rather than what you need to know.


Categories: Process Management

Building A Backlog: Notes On Asking For Requirements

Asking requires listening and writing down what you hear!

Asking requires listening and writing down what you hear!

Asking stakeholders to describe or define requirements is the most common way to develop requirements for projects. Specific techniques include talking to stakeholders in the hall informally, interviews and questionnaires and very formal joint application design (JAD). These techniques are popular because asking and talking to people is easy and opens a dialog. However, while stakeholders may know their business need, they may not know the details of what they really want and need. Moderation and planning are critical for making all of the techniques in the category as effective as possible for creating an initial backlog. Examples of how moderation and planning could be implemented in two classic “asking” techniques are shown below:

Joint Application Design (JAD) is a very formal technique that is an off-shoot of Joint Application Development that evolved in the 1970s. JAD is highly structured approach to developing the requirements and design for an application or project. The process is based on the interaction between key roles (sponsor, subject matter experts including business and IT participants, facilitator, scribe and potentially observers). The process requires all roles. It should be noted that the JAD process was one of the earliest techniques used to embed business and IT personnel for any substantial period of time. The process (documented many places including Wikipedia) has a number of key steps that provide a structured approach for interaction and generating information. Setting the goal (one of the key steps) of the JAD acts as an anchor for the process and provides a tool for the facilitator to re-focus the process if it wanders off course. In order for a JAD to work, up-front planning is mandatory. The participants need to be carefully identified, the goals of the JAD identified and a detailed agenda with supporting documentation needs to be developed. Preparing for the JAD can take as long as the session itself. JADs typically run three to eight days and participants typically were sequestered from the typical working environment during the session.   The combination of skilled facilitator and structure help IT and business participants interact in a creative and productive fashion. Overall JAD is a very powerful technique, however the structure and overhead tend to make it more difficult to apply.

In its classic form, JAD is viewed as less than Agile. Historically it was used to develop the much abused, big up-front design (BUFD). Agile principles call out the concept of emergent design, while eschewing the BUFD. The practice of Agile  is generally more a reflection of finding the balance between what needs to be known and what needs to be discovered. I have used the formal structure of the JAD process as a tool to initiate Agile projects very successfully by refocusing the goal to build an initial product backlog. The combination of structure and facilitation is more valuable when a team is addressing a new business area or in matrix organizations where teams are assembled for each new project.

Interviews are another of the classic “asking” techniques. Interview techniques can range from formally scripted question and answer sessions to loosely guided discussions. Formal interview techniques begin by developing a set of questions to be asked during the interview. In formal interview situations, the responses to the questions in the scrip and any follow-on questions captured as close to verbatim as possible. A legal disposition is an example of a formal interview. They require the interviewers to prepare for the interview not only by developing the set of questions to be asked, but also to gather information about the general outline of the answer they are going to receive. A good interviewer is rarely surprised by the answer they receive. Informal interviews are typically less structured, however they still require preparation. In less formal scenarios I generally recommend developing a loose set of framing questions (framing questions capture the direction of interview without being specific) so that the interviewer develops a goal for the interview and then plans the approach to attain that goal. The framing process is important in case the interviewee throws a curve so that interviewer can gradually guide the interview back to the correct track. Take notes (do not trust your memory) in all interviews. While informal interview seem more like common conversation, interviewers that are good at the informal technique tend to good counter-punchers (able to deliver well formed follow questions that keep the interviewee talking) however even in an informal interview, the interviewee must always their ultimate goal in mind. In both formal and informal situations, if the interviewer is emotionally involved in what the answer should be, consider using a facilitator or external interviewer.

Asking stakeholders for requirements is a tried and true method to generate an initial backlog. Asking should not equate to ad hoc or mere order taking. Asking requires preparation to be effective whether using formal techniques based on JAD or informal interviews. As an interviewer you need to map out where you want the session to go and then act as the guide.


Categories: Process Management

Building A Backlog: Three Categories

Requirements don't grow on trees

Requirements don’t grow on trees

Many discussions of Agile techniques begin with the assumption that a backlog has magically appeared on the team’s door step. Anyone that has participated in any form of project, whether related to information technology, operations or physical engineering, knows that requirements don’t grow on trees. They need to be developed before a team can start to satisfy those requirements.  There are three primary ways to gather requirements based on how information is elicited.

  1. Asking: There are many techniques that focus on asking users, potential users and other stakeholders what they want the project to deliver.  Classic examples are joint application design, questionnaires and interviews (formal and informal).  This category gets used most often because of its simplicity (everyone thinks they know how to ask questions). For small and uncomplicated projects simply asking and talking about what is needed may well suffice.  Unfortunately this method can fail if the wrong people are asked and/or if those who are asked don’t know what they really want or need (remember the adage: you don’t know what you don’t know).
  2. Observing: Observation was one of the first methods I was taught when collecting requirements for process changes.  Watching how people work jumps over what people think happens and goes directly to the source. For example, an organization saw a substantial drop in the number of mortgage applications being keyed into the system around lunchtime.  None of the management stakeholders could explain the productivity change well. In order to get the bottom of the issue we observed work in the department for a week. What was found was the form was long (many pages) and forms not completed before lunch were lost and had to be restarted. The system was changed to allow portions of the form to be saved and then restarted, increasing throughput in the department. One of the drawbacks to watching is the impact of observation. As noted in the Hawthorne effect, paying attention to people can impact the output of the process, thereby generating false information.  Further, in cases where trust is an issue, observing a group can generate panic.
  3. Showing: Prototyping (functional or paper) or delivering functional products that stakeholders can interact with and react to are both great ways to push requirements past what is known and currently possible.  Paper prototypes are a mechanism for helping team members and stakeholders visualize how work could be done.  Some techniques start with how work is currently done, then visualizes change. Functional prototyping delivers software that functions at some level.  Functional prototyping requires planning and effort as if a project in its own right.

Each of these categories can be overlapped to create hybrids.

An initial backlog is built at the beginning of a project, or at least very early on. If your organization has a strenuous budgeting and strategic planning process, the more that you will need to generate a detailed initial backlog before the team starts to work.  Whether a team develops just enough of a backlog to get started or builds a broader backlog, they need have a backlog before they start developing. Backlogs don’t grow on trees!


Categories: Process Management

My Primary Criticism of Scrum

Mike Cohn's Blog - Tue, 07/22/2014 - 15:00

On the first day of my Certified ScrumMaster course, we go over the agenda for the two days. I point out that one topic we’ll cover will be “meetings.” I usually point out that Scrum is often criticized for the amount of meetings it defines. I then claim that this is a pretty weak criticism of Scrum because most of the meetings really aren’t very long, and that if we wanted to, we could find better criticisms of Scrum than “Scrum teams meet too much.”

After saying that, I always expect someone to ask for an example of a better criticism of Scrum. But usually, no one asks and I move onto the next topic.

And since I think it’s important to remain critical, I’d like to use this post to share one of my own criticisms of Scrum.

The strongest criticism I’d levy on Scrum is that many Scrum teams have become too focused on checking the boxes to say they are done with something, and less focused on finding innovative solutions to the problems they are handed.

Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.

In today’s version of Scrum, many teams have become overly obsessed with being able to say they finished everything they thought they would. This leads those teams to start with the safe approach. Many teams never try any wild ideas that could lead to truly innovative solutions.

I believe a great deal of this is the result of the move to shorter sprints, with two weeks being the norm these days. Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.

I’m willing to take my share of the “blame” for the prevalence of two-week sprints. I’ve certainly been vocal in my preference for that length (while remaining open to whatever is right for a given team). And, I still think two weeks is the right length for most teams. Two weeks is also my default, initial recommendation to a team until I know more about them.

So, as much good as a shift toward shorter sprints have done for Scrum teams, for many teams, it has come at the expense of creativity, experimentation and breakthrough ideas.

I don’t think the answer is for all teams to instantly revert to four-week sprints. I think mature Scrum teams have found ways to balance the pressure to get things done with the benefits that come from occasionally pursuing long-shot ideas that sometimes pay off.

So, there’s my biggest criticism of Scrum as I see it practiced today. What’s yours? What problems do you see with Scrum as defined or as it’s commonly practiced today?

How Requirements Are Captured Really Matters

Capturing requirements is different than catching fish.

Capturing requirements is different than catching fish.

Where do you get the requirements that make up your backlog? There are two classic macro strategies that project teams follow to gather requirements and create a backlog.  Where a backlog of requirements comes from and who was involved in the process has implications that can influence the whole life cycle of a project by setting expectations and identifying behavioral norms for the entire project.

The first macro category represents scenarios in which requirements are provided to the project team either fully or partially formed. This is very common for projects that are outsourced or in organizations where a significant barrier has been erected between corporate IT and the business.  The business decides what it wants and then negotiates to obtain what they are asking for.  In order for this scenario to work effectively, business departments hire business analysts (BA), create shadow IT teams or leverage super users to act as liaisons to IT.  The BAs, or proxy BAs, gather and document the businesses requirements, and then during the project execution, they interpret those requirements.  This type of behavior reinforces a barrier between the business and the team doing the work.

One of major problems this arm’s length process of gathering of requirements generates is an anchor bias in which the business’ expectations get set before they know what is possible.  The backlog becomes the baseline against which project success will be measured. Change and evolution become more difficult because changes would be perceived as renegotiating success.  Applying the Agile principal of embracing change and working with the business on a continual bias become significantly more difficult when the business has become anchored to the picture the initial requirements generates.  This anchor becomes even stickier when those requirements are codified in a contract or as success criteria in a charter (a weak form of a contract).

Another behavior that falls into this category is that the BA becomes a proxy for the product owner.  Proxy product owners don’t have the decision making power to change or evolve the backlog, so they tend to defend the status quo.  A better solution is to incorporate the BA into the project team with a true product owner.

In the second macro category the whole team, or at least a cross-functional portion of the team, gathers the requirements.  In an Agile project, the requirements are used to generate an initial backlog. Incorporating the requirements into backlog is an explicit recognition that the project will allow the requirements to evolve.  Involvement of a cross-functional team will produce better requirements earlier, while incorporating Agile principles and backlog concepts help parties stay less anchored to the initial requirements given the flexibility inherent unthreatening techniques. Removing or diluting the initial anchor makes it easier for the product owner to identify and incorporate the concept of a minimum viable product into release planning.  Without the anchor the project will not be perceived as all or nothing because the backlog can be re-prioritized or changed if needed.

The cross functional approach to developing requirements that includes business, BA, development and testing capabilities build bridges between IT and the business.  These bridges make it less likely that the BA will have play the role of proxy product owner, because business personnel have more exposure to the project environment, making it less foreign and frightening.

How the initial set of requirements defined and who participated in the process can have a huge impact on the trajectory of a project.  Whether organizations perceive IT as a partner or as a vendor will influence which requirements strategy will be most attractive, as will how dynamic the organization perceives the business environment. Partnership and dynamic environments tend more towards scenario two.  In the long run, all projects have to have a set of requirements. How we organize them will affect the how, who and when of gathering requirements.


Categories: Process Management

SPaMCAST 299 – Systems Thinking

Listen to the Software Process and Measurement Cast 299

SPaMCAST 299 features our essay on systems thinking.  Many process improvement programs falter despite our best efforts because they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. Systems thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather than simply based on a single event.  The essay begins:

In a world made up of interlocking systems, understanding requires defining a set of general principles independent of the system being measured. At a more finite level, such as a company or product, understanding systems is crucial for being effective and efficient.  Many process improvement programs falter when, despite our best efforts, they don’t improve the overall performance of IT.

More? Listen to SPaMCAST 299!

Next week is show 300!  We will feature our interview with Vasco Duarte. We discussed #NoEstimates.  The topic of #NoEstimates evokes a great deal of passion.  Our interview will embrace that passion and sort through the noise to get to the core of the idea which is highly useful despite all of the controversy.

Upcoming Events

Upcoming DCG Webinars:

July 24 11:30 EDT – The Impact of Cognitive Bias On Teams
Check these out at www.davidconsultinggroup.com

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute(ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 


Categories: Process Management

SPaMCAST 299 – Systems Thinking

Software Process and Measurement Cast - Sun, 07/20/2014 - 22:00

SPaMCAST 299 features our essay on systems thinking.  Many process improvement programs falter despite our best efforts because they don't improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. Systems thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather than simply based on a single event.  The essay begins:

In a world made up of interlocking systems, understanding requires defining a set of general principles independent of the system being measured. At a more finite level, such as a company or product, understanding systems is crucial for being effective and efficient.  Many process improvement programs falter when, despite our best efforts, they don't improve the overall performance of IT.

More? Listen to SPaMCAST 299!

Next week is show 300!  We will feature our interview with Vasco Duarte. We discussed #NoEstimates.  The topic of #NoEstimates evokes a great deal of passion.  Our interview will embrace that passion and sort through the noise to get to the core of the idea which is highly useful despite all of the controversy.

Upcoming Events

Upcoming DCG Webinars:

July 24 11:30 EDT – The Impact of Cognitive Bias On Teams
Check these out at www.davidconsultinggroup.com

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute(ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

The Case of the Not Daily, Daily Stand-up Meeting

UntitledWhen it comes to the daily stand-up meeting, one of the process “improvements” I occasionally see is changing them to periodic stand-up meetings.  Generally teams do this when 1) non-Agile projects use the stand-up meeting technique to share statuses, 2) they are doing large tasks that do not require coordination, or 3) when an Agile team misunderstands the purpose of the stand-up meeting.

Project plans and schedules are an important tool to coordinate and direct team members in non-Agile projects. The intent of project plans and schedules is to provide team members with a sequential list of to-do items.  The schedule is to a non-Agile project what sprint planning and the daily stand-up meeting is to an Agile project.  Where work is highly deterministic, nothing goes wrong or nothing new is discovered the process works great.  Non-Agile project managers often leverage the stand-up meeting technique to gather status and feedback to help them control and tune their project schedule. These stand-up/status meetings are not typically needed on a daily basis given the belief in the pre-planned schedule and a project manager, rather than the team, who is responsible for adjusting the plan.

During sprint planning, Agile teams break work down into more granular chunks.  This process serves multiple purposes including helping team think through the process of delivering the work, generating milestones to show progress and to evoke additional feedback. The level of granularity that work is broken into varies from team to team and from function to function.  For example, installing a new server might be broken down into more granular task such as, installing a new rack, running power to the rack, mounting and hooking up the server (teams will add more or less detail depending on their needs). The more granular tasks would be completed individually more accurately showing progress. Some teams decide to hold their stand-up meetings on a less frequent basis to reflect the lack of change on a day-to-day basis. Assuming that the team has a common goal and that team members are working on stories related to that goal or tasks that are part of the same story a better solution would be to break the work down in to smaller components.

A related reason teams give for not needing to do daily stand-up meetings is that work they are doing is not related, and therefore hearing about what someone else is doing is only of tangential interest.  Actually words like ‘boring’ or ‘overhead’ might be used.  I tend to agree with this rational, if team members are not working on tasks that are related to a common goal or story or they are working on items where inter-team coordination and communication won’t add value, then don’t do daily stand-up (perhaps don’t do them at all). HOWEVER I am unsure whether I would call this assembly a single project or the group of people doing the work a team.

Every once in a while I find a team that has truly embraced the Agile principles, but have misunderstood the rational for doing stand-ups. Most the teams in this category are highly cohesive and expend a significant amount of energy communicating and coordinating between members.  Many times groups in this category see the formal stand-up as a ritual that they found other, informal means to address. Daily stand-up meetings are a time for the whole team to gather, interact, coordinate work and offer advice.  If an Agile team has found another means get the whole team together to interact, coordinate and communicate, the formal daily stand-up is not needed.  Generally, however, what I have observed is serial one-on-one conversations rather than true group interaction. There are much more prone to imperfect communication (see telephone game), and lacks the diversity of opinion group interactions can give.

Sometime daily stand-up meetings don’t make sense. However I typically find that when that is true the real issue is that the either the team has not really embraced Agile or are not working towards the same goal.  Every once in a while a small, very tightly knit team finds a way to continuously interact and coordinate at a group level. They do not need to do a formal daily stand-up – they are doing a stand-up continuously.  Most (99.9%) Agile teams need to do a daily stand-up.  Stand-ups not only reinforce team membership, but more importantly, stand-up meetings are often only time the whole team gathers to share and interact during the day.


Categories: Process Management

Stand-up Meetings: Add-ons

Stay focused!

Stay focused!

 

There are very few add-ons that can make a daily stand-up meeting better. In fact most add-ons shift the focus of the meeting and could easily be classified as process problems. However, there are two add-ons that can add value to the stand-up meeting process: trolling for risks and hand-offs.

Trolling for risks. Anyone that has ever felt responsibility for the outcome of a project has had that nagging feeling that something was lurking just over the horizon that could reduce the value you are delivering. Project risks reflect the potential for something to go wrong. No one wants to have a risk that should be seen coming to catch them off guard. Therefore I periodically add a fourth question to the stand-up meeting questions: “Are there any project risks you are more concerned about this sprint than last sprint?” The goal is expose any new risks or any risks that are becoming more risky. At a project level I suggest adding this to the stand-up discussion once per two week sprint and do not let the conversation expand beyond the 15 minute time box. If the project has suddenly become so risky that more time is needed, I would suggest treating the changed risk status as a blocker and have the scrum master pursue identifying the root cause so that specific action can be taken. Stand-ups for a program (very large project or a related group of projects) may need to monitor risk on a daily basis.

Hand-offs. Project teams are often distributed across continents, which can be used to a team’s advantage so that work begun in one time zone can be handed off and to be continued at the beginning of another team member’s day. This technique is often called “following the sun.” In order for this technique to work, the team members that are involved in the hand-off must understand that the hand-off is occurring, the goal of the shared task and the current status of the work. The daily stand-up meeting plays a critical role in this process. Involved team members can use their update to alert those they are handing work off to about the current status of their shared task or to schedule follow-on discussions if a more in-depth hand-off is needed. One common example of this practice is when developers are in one location and testers in another. The approach is first planned in sprint planning then coordinated during the daily stand-up meeting and other person-to-person interactions. The daily stand-up meeting generally acts as a formal control mechanism while conversation outside the meeting is less formal and more collaborative.

The stand-up meeting serves a very specific set of planning and coordination purposes. Add-ons generally push the daily stand-up meeting away from that purpose therefore become process problems. There are a few add-ons that fit well within the purpose of the meeting and the 15 minute time box. These add-ons focus on planning and coordinating and help the team get their work done rather than reporting on how the work is being done.


Categories: Process Management

How Stand-up Meeting Go Wrong: Process Issues

Stand-up Meetings are not just a presentations.

Stand-up meetings are not just a set presentations to scrum masters.

A team’s daily stand-up meeting is an execution of a process, a series of steps taken to achieve a purpose.  Stand-up meetings lose effectiveness when they don’t follow a process, when participants try to multi-task during the meeting, treat the scrum master like manager or when stand-up meeting becomes a status meeting. All of these problems are process problems.

Stand-up Meetings Without a Process  Stand-up meetings are daily planning meetings. During the meeting the team sorts out what has been completed, what will be accomplished in the near term and whether there are any “blockers” inhibiting progress.  There are numerous approaches that can be used to do stand-up meetings, including the famous three questions approach and walking the board. The team should leverage more than one technique on a regular basis to keep the meeting fresh.  What should never happen is for a team to abandon structure and just hope team members will share all pertinent planning and problem information.  The job of a scrum master/coach is to ensure the team has a pallet of stand-up techniques and that those techniques are used.

Multi-tasking  One of reasons stand-up meetings work efficiently is that they are short and focused.  The meeting should be 15 minutes (or less).  Nearly everyone can focus on one thing for 15 minutes without doing something else (like day trading or checking email on their smart phone).   I strongly urge all teams I work with to ban smart phones or any other electronic tools during the meeting UNLESS absolutely needed to view the team board (video, teleconference or Agile tool).  I have even gone as far to suggest that phones be put on the floor during the stand-up meeting.  Fractured attention reduces interaction. Recently I was walking through Little Italy in New York City after dinner.  As I walked past restaurant after restaurant, I noticed that many diners were sharing their attention between their phones and their dinner party, reducing the conversation at each table.  Stand-up meetings ONLY work when the team is sharing and listening.

Reporting to the Scrum Master  Stand-ups are a team meeting.  The team members talk to and interact with each other.  Occasionally the meeting might require some facilitation, however the communication and interaction needs to be between team members. They are ones writing the code, testing the software, building the hardware or writing documentation.  The scrum master/coach is the facilitator, not the focus of the meeting.  Team members must address each other not the facilitator.  One technique I learned early in my coach career was to stand behind the team rather than in front of the team or in front of the team board.  Team members will tend not turn around to face the coach, so they will make eye contact with their team members instead.

Status Meeting  The single worst process problem is converting the stand-up into a status meeting (or any other kind of meeting).  Just don’t make this mistake.  If a meeting to collect and discuss the status of a project is needed, first do the stand-up meeting, end the stand-up meeting and then reconvene a separate meeting. The Scrum master/coach should draw a very distinct line between meetings, even if people don’t leave the room so that no one confuses the purpose between the two sessions. For example, in organizations where stand-ups are done standing up, I have had team members sit down to mark the change of meetings.  Another example, when I have done distributed stand-ups, I invite everyone that needs to attend the second meeting to hang up and re-dial.  This clean break makes it easier for people that don’t absolutely need to be involved to get back to work.

The practice of stand-up meetings is one of the first techniques most organizations adopt when they begin to implement Agile.  Because of the simplicity of the technique, organizations forgo coaching or training on how to do stand-up meetings. They rely instead on the best efforts of everyone involved.  Without coaching stand-up meetings can be implemented poorly, robbing the organization of the benefits of the technique.


Categories: Process Management

How Stand-up Meetings Go Wrong: Team Issues

Bad attitude!

Bad attitude!

The daily stand-up meeting is an easy Agile practice to adopt and an easy process to get wrong.  When an organization or a team gets stand-up meetings wrong the problems tend to stem from either a people or a process problem.  Each category can be broken down into a number of more specific problems, each with different symptoms and solutions. Today we’ll talk about people problems. People problems are really team problems. Teams are made up of the interactions between people pursuing a common goal.  Each person has his or her own motivations, goals and biases.  Because teams are made up of people, teams are complex and chaotic.  Stand-up meetings can be a window into structure and health of any team.  Some typical symptoms seen in stand-up meeting with engagement problems are passive aggressive behavior, poor stand-up attendance, tasking personnel and controlling behavior.

Passive aggressive behavior between individual members  This indirect hostility is sometimes seen as members exchange information during the meeting.  The scrum master/coach should work with the individuals to identify and rectify the behavior.  I generally feel that this type of behavior is difficult to address as a team or in a retrospective because there is often too much personal defensiveness.  If the problem cannot be solved at the team level get a line/HR manager involved, but do this only as a last resort.

Poor attendance  Assuming that there isn’t a scheduling problem, poor attendance reflects how much the team values the stand-up meeting.  If this is a problem, the scrum master/coach should schedule a retrospective to help the team uncover the root cause for the attendance problem.  Attendance problems are generally a reflection of how team members value each other.

Tasking meeting  Stand-ups in which a leader hands out tasks to the team show that the team (or a manager) has not embraced the core Agile principles of self-organized and self-managed teams. In this situation the team either can’t or won’t engage in managing the work.  Start addressing the problem with training and coaching, both at the IT management level and the team level, to drive home how the Agile principles should be practiced.  If an organization or team can’t stop tasking team members, longer-term organizational change is needed. Until that can be accomplished the primary value of Agile is out of reach.

Controlling behavior  Behavior in stand-up meetings often reflects behavior outside the meeting.  Teams generally have a leader, however when a person crosses over the line and becomes dominating, teams can lose the potential advantages of diverse voices. This type of behavior is most common when parts of team are at a power disadvantage. For example, contractors are often placed in subservient position if someone on the team controls their contract renewal.  When this issue is discovered, the scrum master/coach should begin with one-on-coaching change the behavior. Beginning with the specific team members in a problem makes sure no one feels blindsided (this is rarely a conscious behavior). Secondly, I find that after the team members are aware of the problem, it is helpful for the team to address the issue using retrospectives.

A good scrum master/coach needs to look for coachable moments to recognize and confront the problems. Where the issue is more systemic, techniques like retrospectives and training can be brought to bear. In the end everyone involved have to recognize the symptoms, but treat the problems.


Categories: Process Management

When Don’t Daily Stand-up Meetings Make Sense

Superman probably does not need a stand-up meeting but Clark Kent is another story!

Superman probably does not need a stand-up meeting but Clark Kent is another story!

The daily stand-up meeting has become a nearly ubiquitous feature of Agile projects and also can be found in Kanban (lean), support projects and even in some waterfall projects.  Proliferation of the stand-up meeting shouldn’t be surprising – the meeting is simple, typically short and easy(ish) to implement.  However, there are a few circumstances where daily stand-up meetings, as we defined them, should not be used.  These circumstances revolve around two general areas, team size (too small and too big) and team/organizational culture.

The guidelines generally quoted for the size of Scrum teams is 7 members plus or minus 2 (5 to 9 people).  This is because of the number of possible combinations of communication channels between team members.  Smaller project teams don’t have all of the skills needed to bring a typical corporate IT project to fruition.  However smaller team can and do exist.  My general recommendation is that stand-up meetings make sense for any team that has more than one team member. A single person doing a stand-up by himself using the classic format is just strange; they should do daily planning.  The same argument could be made for a team of two that does pair development, however taking a few minutes to review what is done and plan the day is the essence of a stand-up meeting.  Larger Scrum teams have just as gray a limit as small teams, however we can all agree that as team size grows, it takes substantially more effort for everyone to stay connected. As team size grows, sub-teams form around specific functions or technical specialties. In other words, the team naturally breaks into smaller teams that communicate more freely.  As teams get bigger than 10 members I find that stand-up meetings begin taking longer (30 minutes instead of 15), generally have to chaired by the Scrum master or an authority figure and become status meetings rather than planning meetings.  I have even seen pseudo stand-up meetings with published agendas. These types of meeting may be occasionally necessary, but I can state categorically that they are not stand-up meetings.

The extremes project-team size aside, the other major reason for not doing stand-up meetings is an environment that does not support the concept of self-organization and self-managing teams. Stand-up meetings, by design, are planning meetings in which team members communicate plans to their peers, solicit and provide support for each other and identify roadblocks to further progress.  The stand-up meeting won’t work in organizations or teams where that type of behavior is not considered appropriate or where managers must gather statuses and dispense work.  Other types of daily tasking or status meetings might be appropriate, but those meetings even if every stands up are NOT stand-up meetings in the Agile sense.  Agile stand-up meetings provide just-in-time planning for teams, and just as importantly empower the team to solve the business problems as a team. Without the planning component, they are merely status meetings.

There are very few good reasons not to leverage daily stand-up meetings.  The extremes of team size, large or small, makes the logistics of a stand-up difficult. Single person projects probably don’t need stand-up meetings; instead I find that reflecting on what I accomplished the day before and what I am going to do today when I run highly effective.  Teams that are too large, probably need to be broken up into smaller teams that can more effectively communicate.  Organizations that don’t embrace the 12 Agile principles ought to put off using stand-up meetings and consider changing their culture first.  But that is a topic for another day.


Categories: Process Management

Simplify Prioritization into “Now” and “Not Now”

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In next month’s newsletter, I’ll write about how to do this within the context of establishing a longer-term vision for a product.

Daily Stand-Up Meetings: The Most Ubiquitous Agile Practice

Preparing for a Daily Stand Up

Preparing for a Daily Stand-Up

The daily stand-up meeting easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.

  1. The team gathers on a daily basis.
  2. Each team member answers three basic questions:
    1. What tasks did I complete since the last meeting;
    2. What tasks do I intend to complete before the next meeting and
    3. What are the issues blocking my progress.
  3. The meeting ends team members’ return to work OR discuss other items.

This is the barest bones version of stand-up meeting.  The meeting is typically attended by the whole team, which includes the scrum master/coach, the product owner and all other team members.  Arguably while the product owner is not a required participant based on the published Scrum guidelines, their central role makes them an important contributor to the meeting when questions about direction come up. I advise team members to discuss whether the product owner will participate (highly recommended) when they develop the Agile team charter and add participation to the team norms.

The most common process addition is the inclusion of a task list/board, either as a physical list often found on the wall of a team room or virtually through the use of a software tool. The team will use the board to guide the discussion.  The tasks they talk about should be on the wall or in the tool.  A rule that is sometimes adopted is that team members do not work on items not on the wall (or tool). The task list focuses the team and provides visual feedback as tasks change status.

You will need to add the following steps to the process when using a list or board:

  1. Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  2. Update the board or tool in as close to real time as possible.

Lists and boards can get out of sync with reality.  Out of sync tools deliver bad information and can lead to work failing through the cracks.  When tools or task list are used they must be kept up to-date. Each team member must keep his or her tasks up-to-date.  This is not the scrum master/coaches role; they not project administrators.

Distributed teams, teams where one or more team members are in a different location, present several challenges, including time zones, accents, organization affiliation and sometimes language. In general, the stand-up meeting should be basically the same, regardless of the participant’s location. What typically does change are the tools needed to make the meeting effective. Videoconference or good teleconference equipment is an absolute must, as is access to the task list (a virtual tool is useful).

You will need to add the following steps to the process when the team is distributed:

  1. Ensure that everyone on the team can see and hear each other.  This typically means securing or scheduling video or teleconferencing facilities.
  2. Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  3. Update the board or tool in as close to real time as possible.

The stand-up meeting is a simple meeting that Agile teams hold on a daily basis to plan and synchronize activities.  Adding lists and tools can make the meeting more effective by focusing team effort, BUT adding lists and tools means that the team needs to keep them up to date and use them!  If we add complications such as distributing the team, virtual tools become a necessity. I have had to ask more than one team what value they were getting from a stand-up if part of the team couldn’t hear and participate.


Categories: Process Management