The Importance of Language in a move to an Agile Culture (with Polling Results)

In my experience in helping teams transform toward an Agile culture, moving away from the traditional terminology and adapting Agile terminology is very beneficial.  At the same time, I have sensed reluctance in organizations in removing from their traditional language.  I believe the language you use matters a great deal if you are attempting to achieve a certain culture.  A prime example is moving from the language of certainty in a more big-upfront Waterfall culture to discovery and hypothesis driven language in an incremental Agile culture.

If you are trying to change culture, the change in language highlights that something has changed and provides folks with a learning opportunity assuming that there is true meaning behind the language and a commitment to change. It makes everyone pay more attention. If you think about it, when you travel from one culture to another, the language does indeed change.  Using the proper language helps you inform and communicate needs more effectively while a common language provides a bond within our community.

Maybe the key is to use language that is most efficient and effective for the culture you want to get to. If you want to change your culture, you need to ensure that the language is not tripping you up and dragging along its baggage of prior meaning.  When you move from a big-upfront Waterfall to an incremental Agile culture, using the same waterfall language will trip you up.

Why? Because people in the organization still think the definition of the term is stemming from the 'old' culture. Attempting to change culture is hard enough and when you have language from the old culture still around, you can be sure that those people within the org are still interpreting the language using the old world context. This can impact your success to advance your new culture. 

With all of that being said, this is the opinion of one person.  So what of the opinions’ of others?  With that in mind, I embarked on a poll via LinkedIn to gauge other’s thoughts on how important is it to use Agile terminology to get to an Agile culture.  I present you with the following results:

Within a period of a month, there were 83 votes cast along with 26 comments.  The poll results revealed that 65% percent (or close to two-thirds) of the participants felt the use of Agile terminology was either ‘Very Important’ or ‘Important’ for an Agile culture.  Another 12% felt it were neutral.  The remaining 23% felt that the use of Agile terminology was of ‘Little Importance’ or ‘Not important at all’.

In order to more fully understand other opinions, I have included a paraphrasing of some of the comments.  They include: there is a need for specialized vocabulary; there are fundamental differences amongst various practices and methods so terminology should be considered; the terminology contributes to language precision; and the words used should work for the culture.  You can see one of the threads within the “Agile” Linkedin group for specific comments from others.

Some took my examples literally.  I didn’t really mean to imply that the term ‘sprint’ and ‘phase’ are the same, but I have seen teams use those terms interchangeably.  So I do agree that one term is not necessarily better than another but that you should ensure the language you use does not get in the way of learning and advancing within your culture.   Also, I’m not clear that there needs to be a standard “Agile” terminology across the industry.  However, with that said, if you are applying Scrum, you should use Scrum terminology (and the same for XP, Kanban, etc). There is a value of having a common Agile terminology within an organization so that there can be a more effective platform for Agile related discussion across teams.  

Also a few people mentioned that the meaning is more important than terminology.  I do favor this line of thinking because there should be an effective meaning behind all terminology used.  Terminology without meaning is babble.  So yes, it is important, dare I say critical to have a well understood and clear meaning behind all the terminology used in order to gain an effective Agile culture. 

Ultimately if you are truly trying to initiate a culture change, then the language should reflect the change you are looking to make.   In this case, if want to establish an Agile culture, utilize the terminology that provides an appropriate and clear meaning which drags little or no baggage.  This will help you get to the Agile culture you may be seeking.  Cheers!

Note: another article that discusses Agile terminology focusing on the terms 'size' vs 'estimate' may be found at: http://cmforagile.blogspot.com/2012/10/size-matters-using-size-instead-of.html

Size Matters – using “size” instead of “estimate” on Agile projects

When I help teams implement Agile methods, I find that some folks have a hard time getting their head around “estimating” user stories (aka, requirements) using story points. When I get to the discussion of Sprint Planning where we are scrubbing stories (aka, requirements) as a team, I used to say it is now time to “estimate user stories”. I would emphasize the importance of having the whole team estimate the story together. I also tend to apply the planning poker technique where each team member has a physical or virtual set of cards with the Fibonacci sequence (aka, law of distribution) of numbers on them (e.g., 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.). When it is time to estimate the user story, each team member selects a card from their deck relating to the story points they think reflects their estimate of the work which should include their notion of complexity and risk for that story.

When I educate folks on estimating user stories, some folks ask me to align the story point with days or hours. That’s when it occurred to me… I realized that when I use the word “estimate” it would make some (many?) folks think of the traditional estimation that uses “schedule” as a measure (e.g., hours, days, weeks, months, years). However, in Agile the intent is to size the amount of work based on the functionality you are building for that story. So in effect in Agile, “scope” is the measure of progress. This is when I realized that folks were often trying to apply a schedule measure because of their familiarity with traditional estimation when in fact, story points is meant to represent the size of the functionality we are building or the scope of the work including the amount of work + complexity + risk of that work. In other words, it was like comparing apples and oranges.

With this in mind, I strongly advocate that in Agile it is much more meaningful and appropriate to use the term “size” as the verb to measure the user stories since this relates to the amount of functionality you are building. This is more than just semantics. This takes us a step away from the traditional mindset where schedule is “king” and moves us to the more important focus of scope since to our customers, the functionality is what is valuable. Now make no mistake, there will be trades offs between schedule and scope, but working software that meets customer needs and provides them value is IMHO slightly more important (e.g., working software over schedule).

It is also important to note that a team’s sprint velocity is a representation of how much functionality can be delivered within a sprint. This is yet another reason why I encourage you to use the term “size” since sizing individual stories relates to the functionality you are building and the sprint velocity relates to how much total functionality is delivered in a sprint.

So if you are having trouble understanding or explaining the concept of estimating user stories, think in terms of the scope of functionality and consider using the term “size” instead of “estimation” to break from the traditional mindset of schedule. So maybe size does matter after all…

Agile Spotlight and Problem Finder

I occasionally hear that Agile is the silver bullet and will solve all engineering problems. In some cases, someone in management heard about Agile and figured it could be a quick fix to solve the challenges within their organization. Unfortunately this is far from the truth. While Agile mindset and methods can help you adapt to customer needs and deliver more effective customer value, one key benefit that I find is that Agile shines a very bright spotlight on the many problems of an organization or product team.

This is where Agile methods such as Scrum, eXtreme Programming (XP), Kanban, Test Driven Development (TDD), and others can be thought of as very effective problem-finding tools. While this is not what most people think about when adopting Agile, it is one of the side benefits. It is important to understand that Agile methods won’t necessarily help you solve the problems that are being uncovered but they really need to be removed to achieve the value delivery and speed you are looking for. More often these challenges have been around for quite some time, well before Agile was introduced. In fact, management and team members have known about these issues, risks, and dependencies, but they conveniently get buried under the organizational carpet. In the Agile world, every impediment can impact the value and velocity of Agile.  Once Agile comes along, the spotlight focuses brightly on anything that gets in the way of efficient and effective delivery of customer value.

What are some of areas where Agile shines the halogens onto existing problems? In my experience, I have encountered numerous challenges during the deployment Agile. Here are some examples:

• When moving to a 2 week cadence of delivery, the team bumped into organizational processes like approvals, alignment of priority and more that slows the team's ability to delivery on a faster cadence. We talked with these dependent and approval groups, shared what is agile and asked if they could work with us on a more regular basis (e.g., bring approval groups in earlier and add a Scrum of Scrums to gain alignment with dependent groups).  
• In setting up Scrum teams, it became clear that there is a lack of QA resources on the project (7 developers to 1 QA engineer). We assessed that our development to QA ratio really needs to be 5 to 3, then replaced some developers with QA engineers. Until we could hire the level of QA engineers needed, we had a few of the developers play the QA role.
• In running incremental QA processes, it becomes clear that there is a lack of automation and, in fact, very few unit tests were ever written. We then spent some time building unit tests to provide at least 80% test coverage (we built this into our Definition of Done), then began automating the tests.
• In running continuous integration, it became clear that there was a lack of understanding the branching and merging process. Developers were unaware of the importance of refreshing the private workspace with latest successfully built and approved code and also continued to retain local objects and executables in their private workspaces. An effective Checkout/Checkin process (with refresh and build and promote) was established and workspace education was conducted by the Configuration Management (CM) engineers for the team.
• In working with a legacy product team, it became fairly clear upon sizing and building functionality on existing code, that we were continually breaking other parts of the code since there was tremendous technical debt within the code base. It was learned that there was no coding standards since the beginning. We initiated a refactoring strategy with coding standards to help us reduce some of the more problematic code modules.
• In working with Product Owners (aka, Product Managers), it became clear that requirements were poorly written which led to a lot of churn between the Product Owner and the developers/QA engineers. The existing requirements list had requirements at multiple levels and it was hard to discern who the requirement was meant for. I educated the Product Owners and Scrum team members on how to write requirements in a canonical form (persona + action + business value) and the POs rewrote the requirements over time in a priority order.

For some teams that move to Agile, they can get overwhelmed by the problems that are identified by the Agile spotlight. In some cases, prior to deploying Agile, it is worth identifying the existing challenges so folks realize they are not caused by Agile. One way to do this is to understand your full end-to-end idea to release delivery process. The key is to add the challenges to your issues list, prioritize them, then address them in priority order. Remember, the Agile spotlight can help you identify some of your problematic areas on the product or in the organization. Take advantage of this but be prepared to address the challenges.  What existing problematic areas have you identified when you were implementing Agile?

Who makes the Best Product Owner?

In one of my recent articles entitled Who makes the best ScrumMaster?, I discussed the attributes needed to make an effective ScrumMaster and what traditional roles may play the ScrumMaster best. From the feedback, those who can best exemplify the attributes of a ScrumMaster made the best ScrumMaster and it did not appear to be strongly aligned with any particular traditional role.

In this article, the focus is the Product Owner role. Much like the ScrumMaster, the Product Owner role is very important to a successfully running Agile team. In fact as teams consider adopting Agile, who plays the Product Owner is critical to gaining the benefits of Agile due to the importance of identifying customer value and enacting the customer validation activities to ensure we are building something that the customer actually wants.

What are some important attributes of an effective Product Owner? A Product Owner recognizes what customers want and translates their needs into meaningful epics and user stories (aka, requirements). A Product Owner must intuitively adapt requirements (aka, user stories) when customer needs and market conditions change, to ensure what is built and delivered aligns with customer needs. This may sound obvious but the Product Owner must have the wherewithal to ensure that the organization in which the team works in will positively support and welcome change. A Product Owner must have the attributes to be a good voice-of-the-customer (VoC) and communicate the customer needs to the Team so they can build what the customer needs. It can be quite challenging to commit time to customers and team members.  Some attributes that an effective Product Owner must have include:

• Parsing customer and business problems and turn them into meaningful user stories  
• Working with sales and marketing to get their ideas into the backlog
• Establishing a directional Product Roadmap and Product Strategy
• Understanding the business marketplace
• Understanding and interacting with the customer domain 
• Establishing effective Customer validation (e.g., end-of-sprint reviews/demos, alphas, etc.) to ensure you are building a product the customer wants   
• Understanding that it takes a trusting environment where problems can be raised without fear of blame, retribution, or judgement, with an emphasis of healing, collaboration, and problem solving  
• Facilitating and influencing the work without coercion, assigning, or dictating

So the question arises, is there a traditional role that plays the Product Owner the best? Let’s examine a few of these roles.

Business Analyst as Product Owner?

What does a traditional Business Analyst (BA) do? A BA is someone who analyzes business needs, works with stakeholders in order to understand their needs, and to recommend solutions that meets these needs. At a deeper level, a BA focuses on eliciting, documenting, and managing requirements. They also act as a liaison between business and technical groups. It is because of the work a Business Analyst already does and in particular their focus on requirements and their liaison role between the business and technical groups that makes them a good candidate for the Product Owner role. A traditional BA would have to gain the experience in working in an Agile manner including the continuous requirements elicitation process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Product Manager as Product Owner?

What does a traditional Product Manager (PM) do? A PM examines the market, the competition, and customer needs and establishes the product direction that is considered valuable to the market and the customers therein. A good PM focuses on the financial considerations including the return on investment (ROI). In addition, the PM is involved in the requirements gathering and management process. It is because of the work a Product Manager already does particularly their focus on what is considered valuable by the customer that makes them a good candidate for the Product Owner role. A traditional PM may not have the experience in working in an Agile manner including a continuous requirements gathering process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Project Manager as Product Owner?

What does a traditional Project Manager (PjM) do? The primary responsibility of a Project Manager is to plan and execute a project from the beginning to closure. A PjM focuses on the project costs, schedule, and scope. A PjM may also help build the project objectives, help manage the requirements management process, manage project risks, issues, and dependencies. While there are some attributes a PjM brings that can help in the Product Owner role, there is very little direct customer focus which is a big part of the Product Owner role so this experience would have to be gained. A PjM may have to unlearn some "assigning work" and "driving the work" as this can inhibit the team's ability to become self-organizing.

Technical Manager as Product Owner?

I have found that some Technical Managers (TM) provide aspects of product ownership to their work. The Technical Manager may get input from Product Managers, Sales, and Marketing and then crafts them into meaningful customer needs.  While there are some attributes a TM brings that can help in the Product Owner role such as crafting a product or service direction, there may be little direct customer focus which is a big part of the Product Owner role. This experience would have to be gained. In addition, a TM will need to break from the "team are my direct reports" mindset and "assigning the work" as this can inhibit the ability for the team to become self-organizing.

Other Roles as Product Owner?
There are other roles that may be considered.  A select example are those in the marketing space (e.g., Market Researcher), service space (e.g., Service Consultant), user or customer experience space (e.g., UX Designer), and entrepreneurs. These are roles that understand the market, customers, and the continuous feedback from the customer.  As organizations have various roles in this capacity, it is worth investigating those current roles that are customer facing and understand how to translate feedback and strategy into user stories. 

Summary

IMHO, those who have played either a Business Analyst or Product Manager can become an effective Product Owner. However, anyone who has played a role where they work with customers to collect their needs and then work with teams to build products or solutions that meet those needs can evolve into an effective Product Owner. I would suggest that anyone who becomes a Product Owner (or is interested in doing so) should consider taking Agile Product Owner education, reading related books, and/or gaining guidance in this area through an Agile Coach in order to help them better understand this role and the activities they will need to perform in order to play this role effectively.

Applying the Agile Canonical Form to write Performance Goals

In most companies, employees have to do some level of performance management. This typically involves each person writing performance goals. For those of you in companies that are adopting Agile (or even if you are not), as you think about your performance goals, one of the things to consider is applying the Agile story writing canonical form as the approach to writing goal statements.

For those of you unfamiliar with the canonical form, it is a language construct that many in the Agile community use to document their requirements (aka, user stories). This includes the role (aka, persona or actor) you are playing, your action, and the business benefit.

In many cases, each of us has a primary role we play within an organization. However, we may also have secondary roles that we play. The canonical construct includes the role so the roles you are playing in your organization or your product team can be effectively added. This may help in describing your goal more effectively. For example:

• As a Scrum Team Member, I will size the work using story points with the team during Sprint Planning, so that we gain team buy-in for scope and size of the story

 • As a ScrumMaster, I will exemplify Servant Leader attributes (and not command-and-control attributes) in order to help my team become self-organized

 • As a Product Owner, I will continuously groom and prioritize the Product Backlog so that the Scrum Team has a solid list of stories in which to work through

 • As an Agile Coach, I will coach and mentor the product team so they can adopt effective Agile methods

 • As an Agile Educator, I will ensure effective Agile instructor-led training is occurring throughout the company

Once you have the performance goal written in this form, then you can list the tangible tasks that make up the goal underneath.  You may consider this another interesting way to use the canonical form (which is usually meant to describe User Stories within an Agile context) for other benefits.

In summary, it is a good idea within a performance goal to identify the role you will play in relation to that goal, what is the action you expect to complete, and why you plan to do that action (aka, business benefit).  Using the canonical form can be an effective way to articulate the performance goal. 

Who makes the Best ScrumMaster?

As teams consider adopting Agile, one of the most important decisions they can make is who will be the ScrumMaster. Because the ScrumMaster is the promoter of Agile values and principals as well as the coach for ensuring the Scrum is being practiced effectively, it is critical that this role be filled with someone who is dedicated to implementing the Agile mindset.

A good ScrumMaster must have the ability to be an effective Servant-Leader. If is important to understand that a servant-leader takes a facilitative approach and does not apply command-and-control. Some key attributes include:

• Building a trusting environment where problems can be raised without fear of blame, retribution, or being judged, with an emphasis of healing and problem solving.
• Facilitating getting the work done without coercion, assigning, or dictating the work.
• Ensuring the implementation of healthy Agile Scrum practices and values are followed on the project.
• Removing roadblocks or find the right level of personnel to remove the roadblock.

In the book “Practicing Servant-Leadership" by Larry Spears and Michele Lawrence, they share attributes for servant leadership. Some attributes include: listening, empathy, healing, awareness, persuasion, and foresight. Anyone who becomes a ScrumMaster should consider taking ScrumMaster training to help them understand their role and the activities they will facilitate. So the question arises, is there a traditional project role that plays the ScrumMaster the best?

Project Manager as ScrumMaster?
The seemingly obvious traditional role to play a ScrumMaster is the Project Manager. However, from my experience, there are pros with having a Project Manager become the ScrumMaster. On the positive side, the Project Manager has experience in being part of the team, so they may already have a trusting relationship with the team. Some Project Managers have built facilitative skills to lead work in a non-directive yet influential manner. And many already have the skills and the insight into an organization to appropriately remove roadblocks. On the negative side, Project Managers typically do not have technical experience into the product and cannot materially participate in technical discussions or provide meaningful technical insight. Also, some Project Managers had success utilizing command-and-control attributes and the more traditional Project Management practices which will not work well (and can be destructive) in an Agile environment. It can also be hard for some Project Managers to eliminate the traditional Project Management mindset of detailed project planning.

Functional Manager as ScrumMaster?
Quite possibly the most problematic role to play the ScrumMaster is someone who is a Functional Manager (aka, line manager, technical manager, etc.). Anyone playing a role where they have successfully directed people must make concerted efforts in removing their command-and-control behavior. On the positive side, they may have some technical experience into the product so can provide meaningful technical insight. They may already have the skills and the insight into appropriately navigating the organization and the ability to remove roadblocks. On the negative side, because they have been a manager of a team, so they may have issues with the team trusting them as a peer since they have been used to being judged by managers. A Functional Manager may have been successfully utilizing command-and-control attributes. However, this will not work well (and can be destructive) in an Agile environment. They must strive to remove their directive attributes and instead build facilitative skills. They must not assign work but instead enable and support team to become self-empowered. These are significant challenges.

Technical Lead as ScrumMaster?
Quite possibly one of the better traditional roles to play the ScrumMaster is someone who is a Technical Lead (QA Lead, Development Lead, etc.). By “lead”, I do not mean a manager or someone who has direct reports, but instead someone who is considered a lead by his peers. This person has a balance of leadership skills while wanting to get the work done. They typically have no interest in directing people. On the positive side, they have technical experience into the product and their specific field (development, QA, technical writing, etc.) so can appropriately aid the work (without direction or coercion and provide meaningful insight). They have experience at being part of the team, so may already have a trusting relationship with the rest of their peers. Because a lead does not have functional management responsibilities, they typically had to build their facilitative skills to lead work in a non-directive yet influential manner. On the negative side, they may not yet have the skills or the insight into an organization to appropriately remove external facing roadblocks.

Ultimately, the best answer to the question of what role best plays the ScrumMaster is not really a particular role, but instead which person best exemplifies the combination of the attributes of servant leadership, understands the Agile values and principles, embraces continuous learning, has a grasp of the technical aspects of the product under development, and can help remove roadblocks. In your organization, are there traditional roles that more often play the ScrumMaster role or best align with the servant leader attributes? If so, what is that role?  If not a role what attributes best exemplify a ScrumMaster in your organization?

----------------------------------------------------------------------------------------------------
PS - if you liked this article, consider reading "Who makes the Best Product Owner".

Daily Stand-up Starter Kit

The Daily Stand-up can be one of the easiest or hardest Agile practice to do well.  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 benefit of the stand-up is that it promotes transparency of what everyone is doing where you communicate your progress.  It can also be a place to help you understand your impediments where you can collaborate on addressing the challenges. The focus should be on:

• What I did yesterday (or since the last time the team met)?
• What I will do today (or until the team meets again)?
• What impediments have I uncovered?  

The daily stand-up keeps the team aligned as to what everyone is doing. The "What I did yesterday" keeps everyone in-sync on what progress has been made.  The "What I will do today" helps you plan for your day and helps you commit to a day's worth of work.  The "impediments" are to share what is slowing you down or stopping you from making progress. Others can help you address the impediment once the stand-up is over. 

One challenge is when either the sharing of these three questions are too vague (e.g., yesterday I work on the same user story) or too detailed.  The key is speaking with detail yet brevity.  Enough details should be shared to ensure people understand what was worked on (e.g., yesterday I worked on opening the port to allow communications to occur) or what will be worked on (e.g., today I will work on setting up the asynchronous protocol and set a test packet through the port).  To keep from going too long, an initial helpful instruction is for each team member to limit their progress to about 1-2 minutes (assuming a team of 7 +/-).

Part of the initial adoption of the Daily Stand-up is simply getting people to go from one person to another and provide your daily progress. A challenge is when the team members expect the Scrum Master to tell you when your turn is.  Instead, consider a round-robin approach where you identify an order amongst the team to share progress. This can be alphabetical by name or around the virtual table by site. Another helpful technique in a distributed setting is ensuring each person introduces 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.  This is particularly useful in a distributed team setting.

Another challenge is that too many team members direct their progress to the Scrum Master (or leader).  Instead, the team should communicate to each other and avoid directing their progress to the Scrum Master. This allows all teams members to know what each other is doing and promotes cross-team communication.

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 progress sharing is focused on the highest priority work first and then so on. This also provides more visibility when the highest priority work 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 challenging and in some cases feel that it is unneeded.  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. Also, the manager needs to realize that when we move into an Agile world, discussion of performance should occur in a more collaborative manner with a focus on progress and learning.

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.

Let us start by considering 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.

Next let us discuss other opportunities to gain employee insight  I suggest using 1:1s with employees to collaboratively discuss challenges, progress and learning needs but evolving it to become a continuous performance review.  These should be a low-key sessions that replaces the "big-bang" performance review.  During the continuous 1:1s, there should be an effort from both management and employee to be transparent and this should avoid any surprises when ratings or compensation matters are discussed. Ultimately, I would like to see the performance review process move away from the stogy and often negative intrustive event and evolve into a continous and collaborative discussion on progress and employee needs.  

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 application lifecycle management (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