Daily Stand-up Starter Kit

When introducing the Daily Stand-up (aka, Daily Scrum or huddle), the initial goal is to get people to share their progress in a brief manner. The team should communicate to each other and not direct their progress to the ScrumMaster. This allows all teams members to know what each other is doing.

Part of the initial adoption of the Daily Stand-up is simply getting them to go from one person to another and provide their daily status (e.g., what did you do yesterday, what will you do today, and what are the impediments). This is usually done in a round-robin manner where the first person says what they did, will do next, and share any known impediments, followed by the next person and so on until everyone on the team has communicated their progress. During the first sprint, you may want to take this approach since it is often the easiest.

An initial helpful instruction is for each team member to limit their progress to about 1 minute. If the team is distributed, then identifying an order amongst the team to share status is very useful. This can be alphabetical by name or around the virtual table by site. Another helpful technique is ensuring each person introduced themselves with their name (e.g., I am Mario…) and ending with a code-word such as “Thank you” or “I’m done”, to let the next person know it is his or her turn.

Once the team has a good handle on the daily stand-up, it can be helpful to evolve the process via the Retrospective. This helps the team reflect on the Daily Stand-up and determine if it is satisfying the needs of the team. For example, you may want to view the stories in the sprint backlog in a priority order and ask those that are working on the highest priority work to share their brief status. The benefit of this is that the team can more readily be aware if the highest priority work is getting done. Because the Agile mindset focuses us on working on the priority work first, this ensures that the status sharing is focused on the highest priority work first and then so on. This also provides more visibility when the highest priority stories are not getting done especially when others are getting done. It then can help you rally resources around the higher priority work that isn’t done.

The key is to adopt, reflect, and adapt. Good luck on your Daily Stand-up journey. How do you conduct your Daily Stand-up and have you evolved it over time? If so, in what ways did you evolve it?

Gaining first-hand insight into Employee progress within an Agile World

In the Agile world, some people find the performance review process a bit tricky. Because we are moving from a more command-and-control environment to a team empowerment environment a person acting in the manager role (e.g., functional manager, resource manager, etc) seems to have a harder time understanding what their employee is doing. Why does it appear harder? First, the employee is not (or should not be) taking work orders from the manager any longer and instead, the work should be driven from the product backlog (via the sprint backlog from sprint to sprint). Second, the manager actually does have less visibility into what the employee is doing since the employee should be 100% commited to their Agile Scrum team. So what should a reporting manager do? I’ve heard about conducting a 360 peer evaluation, but this is basically second-hand information. The question is, is there a way to gain first-hand information? What I recommend are the following ideas that can help a manager who has folks who report to him or her that are on an Agile (or Scrum) Team.


First consider the areas along the Agile process where a manager could gain direct insight into what the employee is doing. The two Scrum practices where a manager could listen into what their employee is doing is the Daily Stand-up and the End-of-Sprint Review.

During the Daily Stand-up (aka, Daily Scrum), the manager can quietly listen into the progress that the Scrum team members communicate during this brief meeting. Before you do this, contact the ScrumMaster and verify that this Daily Stand-up is an open meeting that you may quietly attend. If you do so, ensure you tell your employees that you may be sitting in on the Daily stand-up. If you have employees on multiple Scrum teams, you may not have time to sit in on all Daily Stand-ups. Instead of sitting in on random Daily-standups, a tip is to attend the same Daily Stand-up for 5 consecutive days so you get an idea of the work done by your employee for a weekly period (for continuity and consistency). Since the Daily Stand-up focuses on what the team member did yesterday, what they are planning to do today, and their risks, you will have some idea of how story and tasks are connected to the work of the employee and how well they are completing the work.

During the End-of-Sprint Review, you can potentially understand the employee’s progress by seeing what they demo (assuming the team members conduct the demo and not the Product Owner). If you learn that your employee is demonstrating work software during the sprint review, then you can quietly listen in to see what the employee built and how it works. Before you do this, contact the Product Owner and ScrumMaster to verify that you may quietly attend the meeting. If you do so, ensure you tell your employee that you may be sitting in on the End-of-Sprint Review for transparency.

You may notice that I emphasize “quietly” a couple of times. The key is that the Agile practices that I am talking about are not meant for the manager per se but for the purposes of building customer value and making progress through the project. The Daily Stand-up is specifically meant for the team members to communicate to each other on their progress. The End-of-Sprint Review is meant to gain valuable customer and Product Owner feedback so that we can ensure we are building the right product for our customers.

What do you think of these ideas? Are there other ideas you have seen work successfully where a reporting manager can gain first-hand insight into their direct reports without obstructing the progress of an Agile project or the employee themselves?

Building Agile into your ALM Solution

What is a good ALM solution? I define ALM to be a set of tools and practices that work together across the project lifecycle, from inception into production, to help you deliver an instance of a product (aka, a release). A reasonable ALM product will have a common user interface for utilizing the ALM functionality. It will also include a meta-model and process engine to parse and share information across and amongst the various functions within the ALM framework. IMHO, I believe ALM is still relatively immature and I don’t sense that there are strong business reasons for doing ALM and still lacks the true integration that is needed to make it seamless. So what would a business drive ALM framework look like? This is where Agile comes in.

I believe a key driver to ALM is focusing on customer value from inception to release. This is what an Agile mindset brings to the table. While many ALM frameworks start with planning or requirements, I suggest agile ALM begin as early as inception or during the creation of the business vision for the product or a specific release. This helps provide the context of the customer value that is being built during the project. Agile ALM also should include mechanisms that focus on customer validation along the way and effective product delivery.

What I am advocating is introducing the notion of the value chain. This concept has been around since at least 1980 when Michael Porter established his value chain framework and further explained in his 1985 book, Competitive Advantage: Creating and Sustaining Superior Performance but the concepts had been discussed in conferences and companies well before this time. I suggest taking the ALM framework, merging it with a customer value chain framework, all while applying the agile methodology of iterative and incremental approaches ©. This integrated framework emphasizes customer value and validation in an iterative and incremental approach. The primary value of my ideal Agile ALM framework is that it provides the mechanisms that enable continual focus on the value of what we are building for our customer throughout the lifecycle so that we ensure we are delivering of value.

To gain more detail about what I believe to be an ideal yet effective Agile ALM framework that is focused on delivering customer value, consider reading these articles:

• Agile ALM for Delivering Customer Value - Part 1 of 2 - published in the Configuration Management (CM) Journal - January 5, 2012

• Agile ALM for Delivering Customer Value – Part 2 of 2 - published in the Configuration Management (CM) Journal - January 11, 2012

Agile Definition of Done Starter Kit

I often find it amusing when the definition of ‘done’ in Agile is sometimes called ‘done-done’. This is meant to imply that we are not just done with development (the 1st done), but we are done with testing (the 2nd done) as well. However, if you think about all of the activities that are needed to get stories in a sprint backlog into the shape to be potentially shippable, you should probably call it “done-done-done-done-done” and possibly more (LOL).
 
So what is the importance of done criteria? First as mentioned, it helps the team understand what is the expectation of getting a story (or the functionality therein) into shape to be potentially shippable. Second, it helps identify the activities and expectations that must occur to build a quality product. Third, all activities in the done criteria are considered when the team sizes the work during Sprint Planning and, therefore, has a direct impact on the sizing of stories. When the team sizes a story, they need to ensure it includes all of the work described in the team’s "done criteria". 
 
As an Agile Coach, I usually bring a starter kit of typical tasks to get a story to "done". This helps initiate an active discussion prior to sprint 1 amongst the team so that each team member understands the various elements of the done criteria and what elements we are agreeing too as a team. Here is my done criteria (aka, definition of done) starter kit:

• Incremental designing (and what type of design type(s) the team will use)
• Incremental development (per the development programming techniques, and this includes developing documentation such as user guides and such)
• Incremental building/evolving the unit tests
• Consideration for incrementally building out automation for regression testing, etc
• Applying appropriate source control, checkout/checkin, and branching/merging
• Applying approach incremental local builds (in private workspace)
• Applying code review (or pair programming if being applied) as appropriate
• Incremental testing (per the testing types, e.g., functional, system, integration, etc., pending how much automation there is)
• Meeting acceptance criteria shared by the Product Owner

At this point, the team discusses these elements and establishes a common definition of done for the stories and the sprint. Now keep in mind that this is the team’s common done criteria and it should be flexible depending on the type of work. Also, once the team agrees to done criteria, expect it to evolve over time and it may be a discussion in the Retrospective if it needs improvement. Some of the effort associated with your definition of done is dependent on what tools, infrastructure, and automation, that currently exists and where you want to go, so keep this in mind.

Finally, if your definition of done has nine key activities, then you can call it the “done-done-done-done-done-done-done-done-done” criteria (LOL).  Maybe just one "Done" is enough.  Once you establish the done criteria for the team, don’t forget to evolve it over time to get you to a quality and releasable product!  

Agile and the Cloud – Match made in Heaven!

Agile and the Cloud are both pervasive these days.  Agile is a software development method based on an iterative and incremental approaches. As most software professionals are aware, the action of delivering the increment into the traditional on-premise software product environment is often laborious and time consuming. Software as a Service (SaaS) conveniently provides shared software products as services, and associated data via the Internet, a model that can be scaled and configured to a company’s or product team’s needs. SaaS changes the software paradigm by providing the software as a service “in the cloud” to companies that need that software product. Companies no longer need local administrators to handle the rigorous and time-consuming effort of establishing on-premise software product infrastructure and the installing the software.

When building products for the cloud, a production-ready environment is made available to many teams almost instantly. While most products require an on-premise installation, building cloud products reduces the need for the often rigorous and time-consuming effort of installing the new releases of the software product infrastructure. Because Agile utilizes an iterative and incremental approach, SaaS products can be incrementally upgraded when the end-of-sprint review (aka, demonstration) indicates that the product is ready. The effort on the SaaS provider side is reduced also, because a few installations by experts are much easier to develop and manage than the many installations by customers (and documentation, ramp-up, and problem resolution that are included).

On the Agile side, the challenge is to build an infrastructure that supports Agile and does not impede the progress of the Agile team that must continue to deliver value. A simultaneous goal is to avoid investment in infrastructure that may not be needed in later phases of the project. One suggestion is to utilize the infrastructure envisioning approach, which applies an incremental approach to the continuous establishment of an effective infrastructure. This is where Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) can be useful to Agile teams. The cloud IaaS and PaaS approaches enable consumers to only use and pay for what they need. This is a distinct advantage for incremental development processes like Agile. This "use-what-infrastructure-you-need" approach minimizes technology debt and allows the team to adjust and scale its needs just-in-time.

As Agile methods continuously build SaaS product increments (i.e. functionality), the cloud deliver them as increasing business value to the customer with little effort from the customer. In addition, the cloud (by way of IaaS and PaaS) provides Agile projects with tools and infrastructure just-in time, so that the team always has the tools and infrastructure they need but never wastefully invests in unused equipment. Consequently, they are able to provide continuous value to the customer in the cloud. This mutually beneficial relationship is a “match made in heaven” for project teams utilizing Agile to build software in the cloud and using cloud infrastructure to support Agile projects. To learn more about on this consider reading the Winning Combination of Agile and the Clouds.

Have you benefited with the Agile and Cloud relationship?  If so, in what ways?  

Agile Culture - Are you Stepping Up?

In the traditional and waterfall world, there tends to be a more directive approach to managing the projects. A hierarchy exists where decisions get made not necessarily based on full knowledge, experience, or information, but based on position. Often times, decisions are made by a few folks and then shared with the team. Ultimately this establishes a culture where folks on the project team become timid, lack enthusiasm, and do not feel vested in the work ahead. This is problematic because we are not getting the most brain power from the team members.

Then along comes Agile. When implemented correctly, the Agile culture places a strong emphasis on team empowerment and ownership. There is little to no command-and-control from management and teams are trusted to make the decisions since they are much closer to the working knowledge and have the experience in that specific area. Team members feel invested in the work ahead because they have a say in the direction of the product.

However, transitioning to an Agile culture does not immediately gain the advantages that you desire. There must be a recognition that managers and some overly directive people need to step back. However, when they do step back, the Agile team membes must step forward to fill the leadership gap. if you want to want to feel invested in your work, you must be willing to own the decisions and work ahead.  Otherwise, those people that stepped back will have a tendency (per their natural inclination to be directive) to want to step forward again.

This is where being assertive and proactive becomes important. Some engineers may come from a culture where they are relegated to “getting instructions” and being told what to do. They are not expected to be a leader. With Agile, it is now their job to become self-empowered, become leaders, and take assertive steps forward.

What does this mean in the Agile context? First, as you become part of an Agile project, you must truly internalize that you are now equally part of the team and your thoughts, experience, and opinions matter. This does not happen overnight because the dynamics of getting to an Agile culture takes time.  In some cases, there will be those working against you, to sabotage the change in order to maintain the status quo. But make no mistake, it is up to you to step up and assertively empower yourself.  Ensure you are weaving your way onto the Scrum team as an effective team member

So next time you don’t think you are appropriately involved on the project or you think you need permission to speak up, stop for a moment. Change your mindset and be assertive, speak up, get involved, become a leader, and start owning the work. Agile provides that opportunity. It is your opportunity to step up.

Agile Animal Farm - Pigs, Chickens, and more

Once upon a time there was a chicken and pig walking down the country road. The chicken turns to the pig and says, “I have a great idea! Let’s start a breakfast restaurant called Ham-n-Eggs”. The pig thinks for a moment, and then says, “No thank you. You would just contribute (your eggs) and could leave when you wanted to, while my bacon would be on the line”.

This humorous yet telling analogy from the Agile world helps us distinguish those that are just involved from those that are truly committed on an Agile team. However, in the real world, pigs do have to work with chickens and even other animals around the farm. Let’s take a look at each animal more closely. I have seen or heard about the Pig, Chicken, Fox, and Seagull before and I will also introduce a few more new animals (e.g., Rat, Cat, and Bull) to this interesting analogy. How many of these have you seen in your Agile workplace?

Pig - They are fully dedicated to the project. This would include the Agile team (aka, Scrum Team), ScrumMaster, and Product Owner. They are committed to the work. They work in a pig-pen with other pigs who love their work and environment and love to pitch-in. If Agile is being implemented correctly, they are more than willing to put their bacon-on-the-line every day because they feel ownership of the work. They are assertive and accountable for the success of the project and have a majority (if not all) of their performance goals linked directly to the success of the project and their specific Agile team.

Chickens – They come and go on the project. While chickens are mostly helpful, because they are contributing their eggs, they don’t always understand the full context because they are not a dedicated team member. So occasionally they may accidently contribute a rotten egg. They are not accountable for the success of the project, although they may have a small portion of their performance goals linked to the success of the project.

Fox – They like to stealthily move into and through the team seeing who has certain skills and ideas. Then they like to steal not only resources (Agile team members) for their own teams, but they also steal ideas. They are not necessarily negative, because they are often so quiet in their manipulative work. They are dedicated to their own success.

Seagulls - They like to fly around the project and not really contribute in any manner. They enjoy “talking” (mostly hearing themselves speak) and pretend they are adding value, but they are only annoying the pigs (Agile team members). Often, they like to swoop in so it can look like they are involved (and they’ll tell others this). They are often quite negative, squawk a lot in a “know it all” manner, and often poop on people and their ideas.

Rat –They are deceiver types who will use the trust of the team to gain insight into topics so they can then “rat” on what is going on to others. Often on Agile teams, they are really deceivers because they are really anti-Agile or just plain negative people. They often know the decisions that are made based on certain contexts that the team is in, but will twist the truth in order to bring the project down. It is important to identify these deceivers as quickly as possible and get them off the team.

Cat – They are a lazy type on an Agile team that really do not pitch in but instead like to sleep instead. They are almost purposefully not assertive, have been used to just “getting by” on projects for years, and are not really interested in feeling ownership of the work. They typically neither positive nor negative and simply like to be left alone. The other team members will begin to notice this behavior and realize they are not really interested in becoming part of the team.

Bull – They are command-and-control types (often management) who think they can continue to tell their folks what to do even though they are dedicated to their Agile teams. Sometimes referred to as bullies, they charge right into the team and attempt to direct them to their own work and often deviate the team from building product functionality. Typically, they are not interested in the Agile mindset because they see it as a challenge to their authority (technical or managerial) or don’t really understand or care about the business benefits of Agile, but instead want to maintain their own status. 

I hope you enjoyed these animal analogies. Did you recognize any of them? What Agile animals are on your Agile farm?

Here are few more links to other Agile animal references:

• Chickens, Pigs, & Seagulls - http://www.scrumology.net/2009/06/10/chickens-pigs-seagulls/
• The Chicken and the Pig - http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
• The Classical story of the Chicken and the Pig (cartoon) - http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/

Enjoy!