Daily Stand-Up Meetings for Distributed Teams

Distributed Agile teams require a different level of care than a co-located team in order to ensure that they are as effective as possible. This is even more true for a team that is working through their forming-storming-norming process. Core Agile concepts are the team and communication, and these are key for the success of distributed Agile teams. Daily stand-up meetings are one of the most important communication tools for teams using scrum or other Agile/Lean frameworks, so it’s important that they function properly.

Here are some tips for making daily stand-ups work for distributed teams:

  1. Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint, so that everyone loses a similar amount of sleep (share the pain). One solution for when distributed teams can’t overlap is to have one team member (rotate) stay late or come in early to overlap work times.
  2. Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties do not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered, so that something discovered late in the day in one time zone does not affect the team in a different time zone (where they might just be starting to work). One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  3. Push status outside of the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI or similar shared document for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  4. Vary the question set being asked. The process of varying the question set for each meeting keeps the team focused on communication rather than giving a memorized speech. For example, ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get competed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams as well.

  1. Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  2. Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion must include the willingness to ask for help and to provide help to team members.
  3. Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table, so that the focus can be on communication. Use of a physical wall in a distributed environment means using video to show the act of someone on the team physically moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that everyone has access to. Keep tools as simple as possible.
  4. Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event; not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they cannot communicate.

Stand-ups are nearly ubiquitous in Agile. However, despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.

Tom Cagley
VP of Consulting & Agile Practice Lead

 

 

Written by Tom Cagley at 05:00
Categories :

Measuring Software Value Using a Team Health Assessment

AgilityHealthSoftware development is a team effort. Agile software development, in particular, depends on a high level of communication between team members. In order to be able to improve the business value they are delivering, it is important that the software development teams conduct regular self-assessments. By taking the time to conduct an in-depth assessment of the key areas that impact team performance and health, an organization can make modifications to their processes to enable continual improvement that can lead to increased business value. 

In Agile, teams typically rely on sprint retrospectives to analyze their performance for continuous improvement. The challenge is that these events are team- and sprint-specific and often become wasteful ceremonies in that they don’t add any new value. 

It is common for the team to reach a point where they have discussed and fixed the things they can fix and the things they can’t fix require organizational intervention, which is outside their span of control. It is easy – and probably correct – for teams in this situation to conclude that sprint retrospectives should be abandoned because, from a lean perspective, they are not adding value and so represent waste to be removed.    

Over the years, our team has leveraged the AgilityHealth℠ Radar (AHR) TeamHealth Assessment as an event to review team dynamics on a quarterly basis. This structured, facilitated event is an opportunity for a more strategic review than the sprint retrospective typically allows..

There are five vital areas that can impact the health of an Agile team: Clarity, Performance, Leadership, Culture, and Foundation. Each should be carefully evaluated to help the team identify their strengths, areas of improvements and top impediments to growth. From there, a growth plan outlining the target outcomes for the following few months can be developed.

The true value of an assessment like this comes from the open and honest conversations that take place enabling the team to evaluate their performance and outcomes and continually improve their processes for the future.    

Does your software development team regularly assess the team’s performance and make adjustments for future growth?  If so, is there a specific methodology your organization uses?


Mike Harris
CEO

Written by Michael D. Harris at 10:09
Categories :

What Does An Agile Coach Deliver?

Tom CagleyI am an Agile Coach, and I'm often asked about the role that Agile Coaches play in an organization. On the most basic level, Agile Coaches help teams and organizations embrace Agile and help maximize the delivery of business value from development. We use terms like "enable" and "facilitate" to describe how we help organizations and teams transform. But what does an Agile Coach actually do? Well, it's a variable mix of activities that includes: consulting, cajoling, training, arbitration, and mentoring.

Consulting

Coaches sometimes act as consultants. A consultant will actively involve him or herself in the game. Sometimes an Agile Coach will have to actively participate in performing a task or activity so that the team can see the technique in action.

Cajoling

Coaches cajole, with gentle urging or coaxing, the team or organization to change behaviors that don’t live up to Agile principles and values. In many cases, this cajoling is underscored by the war stories a Coach can deliver about the trials and tribulations that will ensue if certain behaviors are not corrected. The experiential base is important for the Coach to be able to hold the moral (metaphorically speaking) high ground needed to persuade the team or organization.

Training

Coaches deliver training. Training comes in many shapes and sizes. Coaches will be able to deliver training on a just-in-time or ad-hoc basis based on their own observations of how work is being done.  The goal of ad-hoc training is to ensure that the team or teams understand how to apply specific techniques as they are applying them. I liken this to a form of just-in-time training, which leverages a principle from adult learning that holds that adults retain knowledge better when it can be immediately applied. This does not exclude leading and organizing training as part of the more formal organizational change program.

Arbitration

Coaches arbitrate conflicts and difficult decisions. Projects, whether to transform whole organizations or to implement a set of simple user reports, always include the need to make decisions. Coaches help organizations make decisions so that they can move forward with a minimal loss of inertia. Facilitation for an Agile organization is a skill that is part art and part science – think emotive negotiation (or as a friend of mine calls it “family counseling for teams”).  The best Coaches teach the team or organizations they are working with these skills.

Mentoring

Coaches mentor. A mentor is a trusted counselor who provides guidance, advice, and training, usually at an intimate (one-on-one) level. A mentor needs to be dependable, engaged, authentic, and tuned into the needs of the mentee, so that the transfer of guidance is safe and efficient.

So, when we say that an Agile Coach enables and facilitates, what that really means is that they  consult, cajole, train, arbitrate, and mentor. The art of being a good Coach is knowing what mix of these activities is appropriate for any specific situation. And, as many readers probably are aware, a good Agile Coach can make or break an Agile transformation.

Tom Cagley
VP of Consulting & Agile Practice Lead

Written by Tom Cagley at 05:00
Categories :

Focused on One Goal: Business Value Delivery

Scrum Alliance

This past week, the Scrum Alliance published an article I wrote, “What is Productivity in Agile?.” Productivity can be a painstaking conversation for Agile teams, who are dedicated to following the principles in the Agile Manifesto, aimed at improving productivity, but they are often pulled in the opposite direction by management to achieve a higher velocity.

In my article, I discuss how everyone (IT and the business units) needs to focus on the same end goal – business value delivery. To do this, they must jointly define value metrics and ensure all team members, both in IT and the business side, understand those metrics and are held accountable for achieving them.

I have seen my clients successfully use metrics for Cost of Delay (CoD) and Weighted Shortest Job First (WSJF) to help prioritize their projects based on business value. I believe that having the IT team and business unit collaborate to create relative metrics in these two areas is a good starting point, but it is also critical that everyone is held accountable for improving value. 

Organizations need to put standard processes in place to ensure the appropriate parties (this includes the business unit) are involved in the entire software development process and that the metrics are not being decided on by one individual, such as the product owner. The business units may push back on being so involved in the process as they will expect the IT department to simply do what they have asked. However, if they realize that the collaboration with IT is more than just about efficiency, but also about enabling them to justify the expenditure to management, they may be less resistant to being involved in the process.

Check out the complete article on the Scrum Alliance website. I welcome your feedback on how your team prioritizes your projects.


Mike Harris
CEO

Written by Michael D. Harris at 05:00

Can Function Points Be Counted/Estimated From User Stories?

Trusted Advisor

Introduction

Since the invention of function points (FPs) any time new development methods, techniques, or technologies are introduced the following questions always arise:

  • Can we still use FPs?
  • Do FPs apply?
  • How do we approach FP counting?

These questions came up around middleware, real-time systems, web applications, component-based
development, and object-oriented development, to name a few. With the increased use of Agile methodologies, and therefore the increased use of User Stories, these questions are being asked again.  It is good to ask these questions and have conversations to ensure that the use and application of FPs is consistent throughout the industry in all situations.  The short answers to the questions are:

  • Can we still use FPs? YES. 
  • Do FPs apply? YES. 
  • How do we approach FP counting? The answer to this last question is what this article will address.

Getting Started – Determine the Purpose and Scope

As with any FP count, it is important to identify the purpose of the count and to fully understand how the resulting data will be used.  This will ensure that the correct timing, scope, and approach is used for the FP count.  The following are examples of situations where FPs can be useful.

Purpose: High-level estimate to determine feasibility

If the purpose is to determine the feasibility of moving forward with the project or to complete a proposal, then typically a high-level estimate in a range is adequate. For this count the timing would be "now," and the scope would be whatever functionality is going to be developed. At this point in the life cycle not all information may be available, so some assumptions may need to be made. It is important to document these assumptions so that if the project progresses differently than planned it can be explained. For example, a User Story may state that "As a User I want to have a Dashboard showing application statistics."  It may be too soon to know the exact details, so an assumption of five average complexity External Outputs (EOs) may need to be made.  

Purpose: Estimate for Project Planning

Once a detailed plan is required, then more detailed estimates for effort and cost are necessary. For this purpose, the FP sizing should be completed at the start of the life cycle and updated at each major development stage. For Waterfall it could be at Requirements, Logical Design, and Physical Design phases. For Agile, the timing could be at Program Increment (PI) planning, or Sprint planning or both.  This purpose will require more accurate and thorough data, which requires a more detailed FP count, so more detailed User Stories are typically available. For example, the above Dashboard User Story may be broken down into 5 separate User Stories each describing a specific report: "As a User I want to be able to see a pie chart showing customer complaints by type."  In this case, each report can be examined to determine uniqueness and counted accordingly.

Purpose: Manage Change of Scope

Once a project is underway it is a good idea to track changes in scope to determine if the effort, cost, and schedule are going to be impacted by the change. These types of counts can be completed at different phases or at the time the scope change is identified. Once a change is sized using FPs, estimates can be developed to determine if the change should be incorporated into the current project and/or Sprint, or moved to another project and/or Sprint. A new User Story could be "As a User I want to be able to search customer complaints by type." In this case, a new report would be identified. If the User Story was "As a User, I want to be able to choose the color of customer complaint types in the pie chart;" this would be a change to the initial report we counted.

Purpose: Measure Quality and Productivity

If the purpose of the FP count is to support measuring the actual quality and productivity achieved for a project, PI, or Sprint, then typically User Stories wouldn’t be the source document of choice. This type of count is completed once functionality has been delivered, so ideally one would want to use the "live" system or user manuals to identify the actual functionality delivered to obtain the most accurate measurement. However, if access to the system isn’t available, User Stories may be the only source documentation available. Often documentation isn’t updated after the fact to show changes of what was and what wasn’t implemented so for this purpose it is important to confirm with development staff and/or users what was actually delivered along with referencing the User Stories. 

Utilizing User Stories for FP Counting – Overall Approach

Once the purpose and scope have been determined, the actual FP counting can begin. Applying the International Function Point User Group (IFPUG) rules is the same regardless of the purpose; however, the level of detail and the inclusion of functionality may be different depending on how the data will be used.

Conducting FP counts from User Stories is a bit easier than from other documentation since the majority of User Stories focus on the User perspective of "what" functionality is desired and not on "how" the functionality will be developed and delivered. Sometimes this perspective is difficult to find when looking at Designs or even the flow of physical screens. User Stories by their nature keep the FP analyst seeing things from the User perspective.

The IFPUG counting process starts with defining scope and boundaries and then moves on to identifying data functions and transaction functions. With a list of User Stories, it is more likely that all of this will be decided together as the count develops.

When counting from User Stories, the best approach is to just start walking through them one by one.  Oftentimes User Stories are grouped by categories (e.g. Order Entry, Validations, Reporting, Financials, etc.). If that is the case, it is best to focus on one category at a time. If it is early in the life cycle and the application boundaries are uncertain, it is best to take a first cut at counting the functions. Once the full scope of functionality is known boundaries can be determined and the FP count can be adjusted as necessary.

In following the IFPUG rules, it is important to count the logical functions. This can be difficult depending on the level of User Stories. It would be wonderful if everyone followed the same format and wrote User Stories the same way, but unfortunately that is not the case. One organization may have one high-level User Story for a project, while another organization may write multiple User Stories for the same functionality. One of the benefits of using FPs for sizing is that the method is consistent across all methodologies and isn’t impacted by how the documentation is completed. For example:

High Level – One User Story

  • As a User, I want to be able to enter, update, delete and view orders in the system to avoid manual paperwork.

Lower Level – Multiple User Stories

  • As a User, I want to be able to enter new orders in the system to stop paperwork.
  • As a User, I want to be able to edit orders previously entered in the system to stop paperwork.
  • As a User, I want to be able to delete orders previously entered to avoid incorrect orders be processed.
  • As a User, I want to be able to enter selection criteria to view orders previously entered in the system to stop searching paperwork.
  • As a User, I want the system to use entered selection criteria to display the correct orders to stop searching paperwork.
  • As a User, I want the system to validate the data entered into the fields when an order is added or updated to ensure accurate data is entered.
  • As a User, I want the system to validate the ordered product is "on hand" before accepting the order.

In the above examples, the FP count would be the same. When a User Story seems to be at a high level, it is important to break it down into all of the Elementary Processes (EP). When User Stories are written at a lower level, it is important to look at all of the similar stories together to potentially combine them into the EPs.

The result of the example above is as follows:

User Stories and Function Points

User Stories typically equate to the Transactional Functions (EIs, EOs, EQs); however, it is important for the FP Analyst to also keep Data Functions in mind while analyzing the User Stories. There may not be a list of tables or a data model available, so the FP Analyst may have to assume the ILFs based on the transaction functions.

If early in the life cycle assumptions may need to be made as documented above. Since the User Stories imply the project is automating a manual system then all functions would be new. That would mean that in order to edit or display orders previously entered, they would need to be stored somewhere; hence counting the ILF. 

If at all possible, the FP Analyst should meet with Subject Matter Experts (SMEs) who understand the User Stories to get a full understanding and/or answer any questions. In addition, the FP Analyst should reference existing systems that may be comparable or past counts that may be relevant. FP Analysts usually have knowledge of many types of systems. It is okay to bring that knowledge and experience to the FP count to help identify potential functionality. Of course, everything still should be validated by the SMEs. 

If SME involvement is not possible, or if things are still not clear, then any assumptions that are made need to be documented fully. This will ensure that the FP count can be explained and updated correctly as the project progresses. In the example above, the assumptions document how the complexity was determined (e.g. Product file used for validation on Create and Edit EIs; Data Element Type (DET) assumptions). In addition, any further questions are documented (e.g. Need to check for multiple order Types that could impact the Record Element Types (RETs) and thus functional complexity of the ILF – this may also impact the number of Transactional functions).

Agile Development - Additional FP Counting Considerations

Since User Stories are typically associated with Agile development, it is worth mentioning a few items to consider for the FP counting in terms of timing and inclusion.

FP counting can be completed at the Program Increment (PI) level and/or the Sprint level. The PI usually encompasses the final delivered functionality, so the FP counting is completed normally. For an estimate, the count can be completed at PI planning. For quality and productivity measures, the counting occurs at delivery of the PI. Counting Sprints is handled a little differently.

Sprints can also be counted for estimation/planning and at the end of the Sprint for productivity and quality measures.  However, the sum of the Sprints is often greater than the PI count. The level
at which the User Stories are written can be impacted by the time boxing of the Sprints. For example, an initial User Story may be, "As a User, I want to be able to create a new order." During Sprint planning, it may be determined that the entire function cannot be completed in one Sprint, so it may be changed to two User Stories:

  • As a User, I want to be able to enter general information when creating an order.
  • As a User, I want to be able to enter order details when creating an order.

In this case, the FP count of the Transaction would be as follows:

FP count of user stories

The Sprints cannot be added together to obtain the total FP count for the project. Counting at the Sprint level is usually for internal measures to ensure the PI goals will be attained. It can also point out inefficiencies in the development process. If too much "rework" is occurring, perhaps changes need to made in how the project is being planned and managed. The ultimate goal would be to complete an entire EP in one Sprint and only have to revisit it in a later Sprint if new requirements are discovered.

Conclusion

FPs are the best measure for "size" and can be used for all methodologies and technologies. FPs can be counted from any documentation or from just interviewing SMEs. The most efficient and accurate FP counting uses both supporting documentation and information from SMEs. User Stories are an excellent source of information for FP counting. User Stories represent the User perspective and are typically written in a way that describes the functionality required. So, “Can function points be counted/estimated from user stories?” Absolutely. “What level of granularity is required?” Any level can be used; however, as with any documentation used, the more detailed the User Story the more accurate the FP count.

Written by Default at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!