An Agile team is comprised of a product owner, team members (from all the disciplines needed to deliver the project) and the scrum master. Delivering on the team’s commitment is the ultimate measure of value. The scrum master helps to create an environment for the team to work together. Over the life of a project, everyone on the team has to lead and facilitate for the team to effectively deliver value. (more…)
November 28, 2015
Leave a Comment
October 10, 2015
Leave a Comment
During the heart of winter, when the polar vortex swoops down with temperatures that even my dog finds uncomfortable, my wife and I assemble puzzles. The act of assembling a puzzle is a simple example of the need to balance a system view with a more detailed perspective. Getting work done efficiently and effectively requires both perspectives in some sort of balance.
The process we use for assembling a puzzle begins with opening the box, spilling the contents on a handy table and then propping up the lid so we can reference the big picture. I once had a conversation in a hotel bar with a person who told me that he thought using the picture as a reference was cheating. A little probing suggested that starting puzzles might have been more his actual goal than completing them, due to the time it took to discover the picture. In our process, by contrast, I use completion of the puzzle as the goal and the picture on the cover of the box acts as the high-level requirements. However, as anyone that has ever assembled a puzzle will tell you, to achieve your goal you still need to fit all of those little pieces together. Whether the puzzle you are working on has 100, 500 or 1000 pieces you will have to shift from focusing on the big picture to focusing on the details to find the right fit. The information from both perspectives is essential to fully understand what is required to get from the start of the system to the end of the system in an effective and efficient manner.
Reflecting back to my conversation about puzzles in the hotel bar, by eschewing the big picture, the systems thinking view, my neighbor might have been able to complete the puzzle, but not in the most efficient manner. Meanwhile, a single-minded focus on the big picture, as pointed out in Gene Hughson’s comments to Systems Thinking: Difficulties can cause the equality serious problem of analysis paralysis. Spinning down into greater or greater levels of detailed analysis means a team is delaying its ability to deliver business value. Gene was interviewed for the Software Process and Measurement Cast 268 providing great insights into Agile architecture, software development and management.
In the end, both perspectives are needed to get the job done. Finding the balance between the macro- (systems thinking) and micro-focus is a process in its own right. The balance changes over the life of any project or even iteration. As a team shifts from conceptualizing to developing what is to be done they naturally shift from the big picture to the detailed view. Product owners face a similar journey between the big picture and the detail, however they need to own the goal and the picture on the puzzle’s lid. As a coach, the scrum master needs to make sure the whole team remembers the overall goal and big picture. Systems thinking helps us to understand that nothing happens in a vacuum. Developing an understanding of how we transform inputs into value is critical. However in order to deliver that value, just having the big picture understanding is not sufficient. In order to actually execute, we need to have a handle on the detail also.
October 18, 2014
Hand Drawn Chart Saturday
I once asked the question, “Has the adoption of Agile techniques magically erased risk from software projects?” The obvious answer is no, however Agile has provided a framework and tools to reduce the overall level of performance variance. Even if we can reduce risk by damping the variance driven by complexity, the size of the work, process discipline and people, we still need to “ROAM” the remaining risks. ROAM is a model that helps teams identify risks. Applying the model, a team would review each risk and classify then as:
- Resolved, the risk has been answered and avoided or eliminated.
- Owned, someone has accepted the responsibility for doing something about the risk.
- Accepted, the risk has been understood and the team has agreed that nothing will be done about it.
- Mitigated, something has been done so that the probability or potential impact is reduced.
When we consider any risk we need to recognize the two attributes: impact and probability. Impact is what will happen if the risk becomes something tangible. Impacts are typically monetized or stated as the amount of effort needed to correct the problem if it occurs. The size of the impact can vary depending on when the risk occurs. For example, if we suddenly decide that the system architecture will not scale to the level required during sprint 19, the cost in rework would be higher than if that fact were discovered in sprint 2. Probability is the likelihood a risk will become an issue. In a similar manner to impact, probability varies over time.
We defined risk as “any uncertain event that can have an impact on the success of a project.” Does using Agile change our need to recognize and mitigate risk? No, but instead of a classic risk management plan and a risk log, a more Agile approach to risk management might be generating additional user stories. While Agile techniques reduce some forms of risk we still need to be vigilant. Adding risks to the project or program backlog will help ensure there is less chance of variability and surprises.
October 11, 2014
Leave a Comment
Kaizen is a Japanese word meaning good change. Change in a dynamic business environment has become an accepted norm. Organizations must adapt or lose relevancy. The concept of kaizen has been adopted within the information technology industry as part of core management practices. In business terms, kaizen has been defined as continuous incremental change. You need energy to make change occur, in many cases, a sense of urgency is the mechanism used to generate the energy to drive continuous change.
John Kotter, author of Leading Change and the eight-step model of change, suggests that without a sense of urgency people don’t give the needed push of hard work to make change happen. Urgency begins by providing a focus that helps people to first become aware of the need for change and then pay attention to the need and the factors causing the need by piercing through the noise. (See the awareness, attention, action model). The energy a sense of urgency injects into the process is needed make the step from paying attention to taking to break through complacency and disrupt the status quo.
The need for urgency in the equation for change can lead to problems. The first is the potential for confusing importance with urgency. In a perfect world, we would only want to react to what is both important and urgent. The second problem area is that of manufactured/false urgency. Both problematic scenarios lead to the sapping of the organization’s energy in the long term, which makes it more difficult to recognize and react when real change is needed. If further there is an over reliance on a manufactured or a false sense of urgency the focus becomes short-term rather than strategic.
My first job out of university was as a statistical analyst/sales forecaster for a woman’s garment manufacturer. We had six “seasons” or product line offerings every year. Quotas were set for the sales force (incrementally bigger than last year). The sales management team for regional sales managers to the national sales manager provided constant “motivation” to the sales force. Motivation always included the dire consequences of missing the quota. There was always a sense of urgency, which drove action, including account prospecting (good behavior) and order padding (bad behavior). The manufactured urgency generated both good and bad change, and when things were going well it was pretty easy to sort those out. However, the business cycle has never been repealed and when an economic downturn occurred it was difficult to differentiate the real urgency. Therefore the organization did not make strategic changes quickly enough. A 80 year old firm with 750 million dollars in sales failed nearly overnight.
Urgency can become a narcotic that makes the need real change harder to recognize and harder to generate. Signs of an over reliance on urgency can include:
- People that are “too busy” to do the right thing,
- Generating highly crafted PowerPoint pitches for even small changes,
- Continually chasing a new silver bullet before the last has been evaluated.
The goal of kaizen is to continually improve the whole organization. The whole organization includes empowering everyone from development and operational personnel to all layers of management to recognize and make change. Motivation is needed to evoke good change, however we need to be careful that motivation does not translate to a need to generate a false sense of urgency.
October 4, 2014
Leave a Comment
Hand drawn chart Saturday.
In Scrum there are four-ish basic meetings. They are sprint planning, daily stand-up, demonstrations, retrospectives and backlog grooming (the “ish” part). Whether distributed or co-located, these meetings are critical to planning, communication and controlling how Agile is typically practiced. Getting them right is not optional, especially when the Agile team is distributed. While there specific techniques for each type of meeting (some people call them rituals) there a few basics that can be used as a checklist. They are:
- Schedule and invite participants. Team members are easy! Schedule all standard meetings for team members upfront for as many sprints as you are panning to have. As a team, decide on who will participate in the demo and make sure they are invited as early as possible.
- Review the goals and rules of the meeting upfront. Don’t assume that everyone knows the goal of the meeting and the ground rules for their participation.
- Publish an agenda. Agendas provide focus for any meeting. While an agenda for a daily stand-up might sound like overkill (and for long-term, stable teams it probably is), I either review the outline of the meeting or send the outline to all participants before the meeting starts.
- Check the tools and connections. Distributed teams will require tools and software packages; including audio conferencing, video conferencing, screen sharing and chat software. Ensure they are on, connected and that everyone has access BEFORE the meeting starts.
- Ensure active facilitation is available. All meetings are facilitated. Actively facilitated meetings are typically more focused, while un-facilitated meetings tend to be less focused and more ad-hoc. Active or passive facilitation is your choice. Distributed teams should almost choose facilitation. If using Scrum, part of role of the Scrum master is to act as a facilitator. The Scrum master guides the team and participants to ensure all of the meetings are effective and meet their goals.
- Hold a meeting retrospective. Spend a few moments after each meeting to validate the goals were met and what could be done better in the future.
Agile is not magic. All Agile teams use techniques that assume the team has a common goal to guide them and then use feedback generated through communication to stay on track. Distributed Agile teams need to pay more careful attention to the basics. The Scrum master should strive to make the tools and process needed for all of the meetings fade into the background; for the majority of the team the end must be more important than the process.
September 13, 2014
Leave a Comment
Hand Drawn Chart Saturday
The simplest definition of a community of practice (COP) is people connecting, encouraging each other and sharing ideas and experiences. There are a few basic logistics that will affect the efficiency of a community of practice. On the surface, logistics impact ease and comfort of a meeting but in a deeper sense, impact the ability for members to connect and share information. A basic logistics checklist would include meeting announcements, facilities, and agenda.
Community of practice meeting agenda: (more…)
July 26, 2014
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:
- Someone with experience and training (perhaps a business analyst).
- A knowledge of the user community (knowledge the product owner can provide).
- Planning (time and effort).
- 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.