RTC Adoption Problems: Tool, Education, or Perspective?

An excellent post on practical use of RTC and how it can successfully be adopted.

Best Practices for Building Software Platforms

I work with CLM customers a lot and sometimes I encounter people struggling to adopt RTC. Once in a while the problem is with RTC – a bug, the rare difficult-to-use feature, etc. Once in a while it’s just a technical knowledge thing. For example, if you’re not aware that your Websphere JVM heap space should be no more than half your physical memory, then you’re going to have issues.

And sometimes the problem is human nature. It’s our own difficulty with breaking out of an existing perspective, breaking old habits and old ways of looking at things. These are the most difficult problems to solve, but solving them provides the biggest payback.

Example: Scrum Iteration Planning

To illustrate this issue, let’s say you’re using the RTC Scrum process template. You think that it takes too long to load an iteration plan. You perceive a performance problem. Fair enough.

So…

View original post 1,073 more words

Advertisements

Scaling Agile – How Organizations are really doing it. Or Not…

Updated post based on presentation I delivered at recent 2014 IBM Innovate conference. Here is the link to the actual presentation, click here.

Agile Practices.   What is SAFe?

The Scaled Agile Framework® (pronounced SAFe™) is an interactive knowledge base for implementing agile practices at enterprise scale. SAFe provides organizations with a set of best practices, artifacts and suggested tooling necessary to scale agile from the team to program to the portfolio level. SAFe** aims to address some of the concern that many have had with other Agile methodologies such as Scrum when attempting to scale. Created by Dean Leffingwell, SAFe has been successfully adopted by a number of large organizations internationally, click link to some of their case studies

Over the last 4 or 5 years, I have had a fair bit of experience helping organizations scale agile, see blog post from 2011 on Scaling Agile – Why Scrum isn’t enough,
so have a good feel of how different approaches have worked for me personally. Last year I was invited to attend SAFe training by my company and obtained my certification as a SAFe Program Consultant certification.

Since then I have had several consulting engagements where I have had the opportunity to apply SAFe, along with other approach such as DAD in complex and distributed environments. So far using SAFe concepts has led to more successful engagements as it seems to seems to address a lot of the challenges that enterprise that I have had to work with face.

In my next couple of blog posts, I’d like to give a bit of an overview of the framework while also sharing some of my thoughts and experiences.

Introduction

The “Big Picture”**, shown below, provides a graphical representation the SAFe roles, teams, activities and artifacts necessary to scale agile from the team to the enterprise level.

022214_2335_ScalingAgil1.jpg

Portfolio Level

In the Scaled Agile Framework (SAFe), the Portfolio Level is the highest and most strategic layer where programs are aligned to the company’s business strategy and investment approach.

The PPM (Portfolio and Program Management) team works with the business to gather ideas to drive the Demand Management process. This process produces a set of Investment Themes (or business initiatives) that the enterprise will focus on over the preceding 6 to 18 months.

Here is a short list of some of the key concepts used by SAFe at the portfolio level.

Investment Themes represent the set of business initiatives that drive the enterprise’s investment in systems, products, applications, and services. These are often broken down into a set of business and architectural epics used to plan, execute and track the set of business to ensure the teams aligned with the overall business strategy.

Business and Architectural Epics a large-scale development initiatives used to realize the value of these investment themes. Each Epic captures the business priority, effort estimate (in story points), and expected value and can be further broken down into sub-epics or features as needed.

Kanban Systems is use to assist the PPM team with visualizing the flow of epic-level value along with allowing the organization ot define work-in-progress (WIP) limits to assure an effective flow and to help manage each initiative through to implementation.

Portfolio Vision defines how the enterprise’s business strategy will be achieved and usually requires the creation of a product road map to visually communicate how the different investment themes are being realized via business epics over time.

SAFe is not right for every organization. Some are too small, some are already invested in their own approach and some are not ready for agile at the enterprise level. Whether you follow SAFe or some other approach is not as important as applying lean and agile applying lean and agile thinking to help realize value across the organization. I have been doing this for years in my coaching practice and that is part of what drew us to SAFe. 

The goal for SAFe adoption as this level is to focus on delivering business value quickly. Agile should be about incremental business delivery not team iterations. The cornerstone for this is to have product portfolio management drive programs which drive the delivery of minimal business increments, click here to read more on this topic.

** Scaled Agile Framework and SAFe are trademarks of Leffingwell, LLC

——————————————-

In my upcoming blog posts plan on digging deeper into how organizations are executing their scaled agile transformation with SAFe at the portfolio and program levels. Will also share some of my experience architecting process and tooling solutions to support the various roles required to make these transformations successful

 

Scaling Agile – Why Scrum isn’t enough

Agile Best Practices – Scaling Best Practices for large organizations

While most teams can start using agile practices, such as Scrum and XP, they often run into hurtles when adoption is extended to other parts of the organization.

Most often these challenges (or agile scaling factors) severely limits it adoption.

Recently delivered a session at the Agile Brazil 2012 conference on why most larger teams often must scale Scrum to overcome challenges (such as geographical distribution, organizational change issues) in their environments to success use agile.

Here it the link to the actual presentation.

Presentation Summary

Agile is a highly collaborative approach to software development that focuses on producing high quality “working code” that is potentially shippable at regular intervals. While many aspects of agile are new and innovative, agile practices are derived from many other successful methodologies such as traditional SDLC, iterative development and lean.

Over the last 5 years adopting practices such as Scrum or XP for small collocated projects has become fairly straightforward but we have found that most teams run into problems as their projects move away from an ideal agile team (e.g., 7 +/- 2 people, co-located team, cross-functional skills, self motivated resources all sharing the same vision and drive to deliver potentially shippable code).

Scaling agile to support larger more complex projects and problems often requires strategies that address both the team’s and the organization’s challenges and perceptions with regards to agile practices.

This session focuses on some of the key agile practices that must be scaled to overcome these challenges. The session uses a number case studies illustrating approaches for adopting more disciplined agile practices. In addition we will also cover 2 or 3 specific agile practices that must be scaled.

Succeeding with your First Agile Pilot Project – Lessons from the Trenches

In a follow up to an earlier post regarding, Succeeding with your First Agile Pilot Project, posted on February 19, 2012 by rfeggins, Have coached several additional teams over the last few months and wanted to share some addition lessons that seem common to most teams starting out.

Pilot

While not difficult, agile adoption does take some time to sink in. Often agile teams need 2 or 3 iterations to work though practices related to being self-organizing. Activities such as creating a properly groomed backlog, estimating and report progress all seem to take some time for most teams. Here is a typical timeline that has worked well for me in the past 

Typical Agile Pilot Timeline

 Consider that the teams new to an iterative approach are usually overly-optimistic and the first iteration is usually the hardest. In addition any infrastructure, tool or integration issues must be resolved prior to onboarding the pilot team and starting Sprint 0 activities.

Tips for Selecting a Pilot Project

Pilot selection is usually very critical. Here are 5 key points to consider: 

  1. Duration – Recommended project length at least 8 – 10 wks
  2. Size – Pick a project that can be done by a small cross functional team (between 5 – 9 resources)
  3. Importance – Select a project critical to business (more visibility)
  4. Motivated Business sponsor – an engaged sponsor can help motivates team and/or help remove organizational barriers
  5. Leadership and Experience – How motivated are the potential pilot team members to adopt agile practices 

Key Activities during Sprint 0  

During Sprint 0 planning, take on modest amount of functionality otherwise the team may not be able to complete of the committed stories or a large amount of technical debt may be incurred. Also the perception of the agile projects success may be dimmed or there will be pressure meet the commitment but not at a sustainable pace.

  • Startup Activities
    • Implement core Scrum practices (e.g. daily stand-up meetings, single product backlog, defining “Done Done” for potentially shippable code)
    • Automate processes automated build process , automated testing
  • Capture stores, requirements written in a scenarios format and work with PO to prioritize them
  • Continue grooming the high priority stories and if possible have the team estimate all high priority stories before the initial Sprint Planning meeting
  • Work with embedded testers to build relationships to help pull testing forward based on prioritized stories and user story acceptance criteria.
  • Track test case results to story cards, manage defects from iteration to iteration

Adoption Team

Finally, here are some additional considerations that the team assisting with the  adoption should take into account:

  • Special care must be taken to ensure you have consensus from the project leaders regarding the pilot objectives and the success criteria.
  • Select the appropriate metrics that help guide the team’s adoption
  • Beware of too much oversight by management. Remember the old saying “A watched pot never boils”

What is an agile methodology anyways?

Agile methodologies is a collection of lightweight software development approaches (some would call them “best practices”) that evolved in the mid-1990s and early 2000s in reaction to heavy weight waterfall processes common in most organizations.

Common agile methodologies include Scrum, Extreme Programming, Adaptive Software Development, and Feature Driven Development.

Scrum, one of the most commonly adopted agile method, focuses on quickly delivering value to the customer by breaking up tasks into small units, called “Stories”, which developed in short time boxed iterations lasting from one to four weeks.

Teams are typically between 5-9 people with cross functional skills. Small teams help simplify collaboration and team communication. In some cases multiple small teams are formed when projects require a larger number of development resource to meet the customer goals.

Each iteration involves a team working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders.

Using this approach, teams are able to reduce project risk by providing teams with frequent points for customer input along with focused planning sessions that helps the project to adapt to changes quickly. Stakeholders produce documentation as required.

These and other agile methods promote collaborative planning, teamwork and lightweight development and testing practices. All support one or more of the twelve principles, first articulated in the Agile Manifesto.

    • Customer satisfaction by rapid delivery of useful software
    • Sustainable development, able to maintain a constant pace
    • Close, daily co-operation between business people and developers
    • Face-to-face conversation is the best form of communication (co-location)
    • Projects are built around motivated individuals, who should be trusted
    • Continuous attention to technical excellence and good design
    • Simplicity- The art of maximizing the amount of work not done – is essential
    • Self-organizing teams
    • Regular adaptation to changing circumstances

Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.  Finally, all agile practices use “working software” as the primary measure of progress and value  face-to-face communication over detailed written documentation. And focus on working with the customer (sometimes called the “Product Owner”) to prioritize “needs” based on business value that can be achieved at the start of the iteration

References
Agile Manifesto, http://agilemanifesto.org/ Ambler, S.W. “Examining the Agile Manifesto”. Retrieved 12 December 2011.http://www.ambysoft.com/essays/agileManifesto.html
Beck, Kent; et al. (2001). “Principles behind the Agile Manifesto”. Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.

Succeeding with your First Agile Pilot Project

Successful agile transformations often times require successful agile pilot projects. Often time a successful initial pilot is the most critical step early in a successful enterprise agile adoption. If the pilot project is a success then the organization has a tangible example to get behind but if the project fails (or just fails to meet expectations) then the entire agile initiative could be derailed by critics. Because no one really likes change unless they are driving it.

Here is a presentation a I delivered a few years ago on running a successful agile pilot Succeeding with your First Agile Pilot Project

The presentions covers

  • Picking the Right Agile Pilot
  • Choosing the best set of Agile Practices to adopt
  • Providing the necessary education, tooling and governance
  • Learn and Adapt from the pilot

Picking an Agile Coach – Lessons from the Trenches

Picking an Agile Coach is often a trying task for most organizations. What is an Agile Coach and what qualities make a good one. These are just some of the common questions most organizations have.

As it takes time to really adopt new practices and behaviors, the Agile Coach must be more than just a recently trained ScrumMaster that usually “swoops in” to deliver words of wisdom and then makes a sharp exit. The coach must be able to spend time with the team to help them to become more aware of their workflow and how to collaborate effectively.

In a nutshell, an “Agile Coach” must help the project leaders, and the teams learn how to successfully apply the required agile practices.  The coach must be familiar with how each agile role (e.g.,  Team, Product Owners, and ScrumMaster) are impacted by an Agile Transformation as well as the roles outside the team that are impacted, especially the Project Managers and senior management (e.g., managing triple constraints or how will weekly / monthly progress be collected and shared)

Being an Agile Coach is different than a ScrumMaster leading a project team as it’s more of a transitory role not tied into project duration. However, your success / failures are directly impacted by how the team performs and grows. So while our goal as an Agile Coach is for the whole team to become self-coaching and adept in applying agile.

In many cases, organizations already have some skilled resources with some real-world experience: ScrumMaster who’s led small / medium projects and/or software developers who have worked on agile projects in the past. These organizations need coaches with experience with rolling out and applying agile practices to boost their performance and proficiency in software development as well as to accelerate their adoption of certain practices.

Common interview questions:

  • Years of experience with Agile, Scrum, XP, etc
  • Describe some of your key experiences leading agile transformations
  • Can you share some of the common challenges you ran into as an Agile Coach and how you over came these challenges?
  • How is being an agile coach different from a team lead or project manager job role?
  • Describe what you believe are some of the core practices for a team to adopt to be called agile (. Explore their understanding of Whole Team, Agile Planning to make sure they know more than just Scrum, assuming the team must scale.
  • What are some of the different roles impacted by an Agile Transformation beyond the (PO, ScrumMaster, Team) roles?
  • What techniques have you used in the past to report progress, document team performance, make adoption recommendations,  etc.?
  • Are you familiar with using tools like Rational Team Concert (RTC) to assist with agile planning, dash boarding and Adoption Activities?
  • What measures do you typically collect to determine if the agile transformation is on track?

Understanding core skills

The core skills for coaching agile teams are solid communication skills, such as listening, asking questions and giving feedback.

To engage the whole team, an Agile Coach must be able to provide one-to-one mentoring to the core roles, be effective at running meetings with good facilitation skills along with the ability to intervene when needed.

For example in his book entitled “Leading Teams”, Richard Hackman asserts that three basic types of coaching intervention: Motivational, Consultative, and Educational where he defines a coaching intervention as “any action that seeks to minimize process losses or to foster process gains.”  He further elaborates on these coaching intervention categories in that:

  • Motivational interventions improve the team’s effort by building shared commitment and minimizing free-riding
  • Educational interventions improve understanding and skills on the team
  • Consultative intervention foster process improvement by helping the team become more aware of their (mindless) habits

Further reading