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.

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.

 

 

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.

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.

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.

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.

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.

Follow

Get every new post delivered to your Inbox.

Join 3,546 other followers