Empowerment vs. Leadership, Which One Can You Do Without?

Tags

, , , ,

Recently I joined an employer and was assigned to a company that uses a program management model with projects aligned with a program. This tells you that their projects are rather large. Typically, I work for employers who don’t want to consider programs, let alone projects (everything is operational in nature) and provide little support for their project managers who are acting in the role of program manager. But I digress, while working at this company, I noticed the project managers do 90% of everything. Let me list out the PM responsibilities:

  • Schedule meetings
  • Resolve issues
  • Negotiate, Negotiate, Negotiate
  • Perform financial analysis
  • Schedule meetings
  • Onboard new team members
  • Create document repositories
  • Run down resources to ask about the status of their work
  • Schedule meetings
  • Identify and mitigate risks
  • Manage change
  • Facilitate the change control board
  • Facilitate the change control committee
  • Did I mention schedule meetings?

It seems that most of a project manager’s life is spent in meetings. Either its scheduling, attending, facilitating, and let’s not forget, writing the meeting recap which no one’s reads until someone has to refer to it to perform CYA! PMs could get a lot done if it wasn’t for all the meetings that need to be held to get work done. Why is this? Why are there so many meetings? Some can point to the need for accountability; others can point to the importance of planning; still others can point to the importance of collaboration and transparency. I think there is a larger problem and it is empowerment.  I remember a well-known expert in the project management field who, during a session at a PMI® Global Congress stated that she had asked prominent CEO, COOs, and CIOs, what is the one thing they look for and expect out of a project manager. You know what they mentioned, leadership! And I would agree, with one caveat. In order to have leadership one must be empowered and supported within the organization!

Let’s examine this for a second. Leadership, as defined, by Webster.com is the power or ability to lead other people. The one word that I see in this definition is power. Most project managers do not have the power to lead other people because they are not predisposed to having power. Predisposed, according to Webster.com is to cause (someone) to be more likely to behave in a particular way or to be affected by a particular condition. If you want someone to behave in a certain way one, in charge of others, must give that subordinate the ability to act in a particular way. If a CEO wants a PM to be a leader, the CEO must give the PM the power to act as a leader. Now, some of you may say, but a PM does not necessarily need a CEO, VP, Director, or manager to exhibit power. And I would agree, to a point. I have never in my 20 years of being a project management practitioner, have I seen a PM exhibit power and lead, successfully, without having the support of his/her manager, Director, VP, CIO, or CEO. A PM can have legitimate power if they are in a company where resource report to them directly. PMs can have reward power based on the positive consequences or outcomes that the PM can offer to project personal; or the PM can have coercive power by having negative things happen to project personal. I have seen PMs utilize coercive power and I do not encourage its use. PMs, by creating and getting approval and signatures on a charter document, scope document, or other formal project management deliverables can embody referent or expert power; however, if a CEO, VP, Director, or manager refuses to sign the documents or support the PM, does the PM have power? They may be able to lead, but they do not have power.

Let’s talk about empowerment. In order for one to lead, they must be empowered. Empowerment is an interesting word. According to Webster.com empowerment is to give official authority or legal power to (someone). Wow, when you read that I take it to mean the following: in order for a PM to feel empowered, it must be given to them so they have the ability to lead other people. This isn’t just for a PM, employees must be empowered so they can go and make decisions based on their knowledge and expertise. One reason why there are so many meetings is that employees, and project managers, do not feel empowered to make decisions. One can say that without empowerment, leaders are hindered in their matriculation in a company and therefore are in meetings to ensure CYA in case someone makes a decision that backfires. I would argue that companies have leaders, but those companies don’t empower their employees to so the employees are hindered by their company and they eventually leave their company to become leaders in another company; typically a competitor. There is a saying, leaders are not made, they are born, and some of that is true but I would add this: Leaders can be broken and lose their spirit in dysfunctional and non-supportive companies. Effective leadership needs empowerment. Leadership without empowerment is like some many PMs today, fulfilling the role of a project manager but is unable to make decisions, hold people account, or reward performance.  CEOs, VPs, Directors, or managers need to support and empower their project managers in their jobs; provide them with the tools and training needed and provide constructive feedback on their performance. CEOs, VPs, Directors, or managers need to work with their project managers to get them to excel and once they are excelling, identify others and repeat, repeat, repeat.

Your thoughts?

Advertisements

Agile Requirements – Who, What, When, Why, and How?

Tags

, , , ,

We’ve all heard the statement, “Agile doesn’t need requirements;” well, that is not true in the health care, insurance, financial and other industries. At the heart of software development are the requirements; if there are no requirements, how are the developers creating the new product? When is Done, Done! Typically, a business analyst (BA) elicits the business and non-functional requirements. According to the International Institute of Business Analysis, a “business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.”  According to the Bureau of Labor Statistics, 876,000 business analysis related professionals will be needed by 2020. This is seen as a vital role and based on current trends, is not going anywhere. With the growth in agile project and software development methods, the role of the BA is more important than ever. However, how the BA fits in the agile framework is still a mystery? Agile Requirements Elicitation (ARE™) is a framework that identifies the Who, What, When, Why, and How of requirements elicitation.

The Who

The Who is the agile business analyst, or agile analyst (AA). The AA owns, or shares, responsibility for user story driven development, whole team approach, team change management, sprint risks/issues, and sprint communication. Changing the title from BA to AA introduces the opportunity for learning a new way to perform a new task.  The AA is not focused on BUFR (big upfront requirements), but rather is focused on talking about the requirements and not writing the requirements.

The What

The What is creating the user stories. User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer. They typically follow a simple template:

‘As a <type of user>, I want to <some goal> so I can <some reason>.’

Within the description of the user story, the AA may choose to write bullet points describing functionality or may include process flows if the functionality is complicated or requires validation. According to Cohn (2011), user stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.

The When

The When is typically before Sprint 0. This is when the AA is continuously working with the Product Owner (PO) to identify the new requirements and creating the basic skeleton and plumbing for the project so that future sprints can truly add incremental value in an efficient way. It may involve some research spikes. The AA is also grooming the backlog, adding, removing, or revising requirements based on the additional knowledge obtained from the PO; the PO’s wants becoming  clearer. In ARE™ this work can also be performed in sprint -2 or sprint -1. These are sprints that occur while the development and test teams are working on the current sprint and as we know, changing the scope of the current sprint is not recommended.

The AA is responsible for leading the project team and service areas through release planning session activities up to the 1st release only to keep the team focused, which will be broken down into one – to – many sprints.

The Where

The Where is the Product Backlog. According to Cohn (2004), the agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it’s not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers. According to Prakash (2013) theproduct backlog is a living document. Stories are added, modified, and split into small ones all the time. The backlog can be created during project initiation. From then it grows and is refined as needed. There should be a few stories in the product backlog at the time of Sprint Zero’s start, enough to help the project team demo at least one working feature.

The Why

The Why is requirements engineering. According to Sommerville (2004), requirements engineering is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. Requirements engineering and its deliverable, requirements, are inevitable and serve a triple function (1), may be the basis for a bid for a contract – therefore must be open to interpretation; (2), may be the basis for the contract itself – therefore must be defined in detail; and (3), both these statements may be called requirements. So for contract work, requirements are needed to prove that you, the contractor, have delivered the necessary functionality to your customer and/or PO.

The How

The How is ARE™. ARE™ is an agile process that is specifically geared to eliciting requirements for disciplined iterative project delivery (DiPD™).

A feature is requested by the PO and the AA records the request as a user story and classifies it as an enhancement or an epic. The AA, or agile project management (APM), can then prioritize the new item qualitatively (high, medium, and low). The AA adds the requested enhancement or epic to the product backlog and continues to work with the PO to groom the product backlog. As part of the grooming activity, the new enhancement or epic is either deemed not needed, which means it won’t fix a defect, deferred, which means it is moved to a lower priority in the backlog, or needed and is then updated. The AA continues to work with the PO to refine the enhancement or epic while the AA creates user stories for the higher priority enhancements or an epics. Once the user stories are created, the AA presents them to the APM and project scrum team (which consists of the development, test, design team members) to obtain their feedback. If wireframes are needed, the AA begins to create them; then the PO approves them.

In the prioritized stage, new enhancements or epics are discussed amongst the PO, APM,development, test, and design team members for better understanding and are categorized in the product backlog as ‘Won’t Fix’, ‘Deferred’, or Needed and then given a priority (Must Have, Should Have, Nice To Have). An estimate is given by the Whole TeamSM using planning poker, or some other estimation activity. The estimate is added to the enhancement or epic, or is deemed unestimatable. Once approved, the estimate is added to the upcoming release/sprint scope by the APM.

In sprint 0, the AA works with the APM, to coordinate sprint planning. This is typically 2 weeks, but can be more. The AA creates a release or sprint requirements package, which is the product backlog that contains a list of the user stories planned for the release and/or sprint approved by the PO. The user stories are reviewed and discussed with the Whole TeamSM and decomposed into tasks, sized, estimated, and owned by the Whole TeamSM. A sprint duration can last between 1 – 4 weeks; but at the end of the sprint, a demo is presented to the PO and if approved, the project scrum team moves the working code to the transition and/or hardening sprint(s) that is the predecessor to deployment.

The End

As you can see, the AA’s role is more collaborative and as more important in agile software development and agile project management as it is in the traditional software development world. Requirements are needed and can be used in agile; the format is not a word document, they are just-in-time requirements. The requirements are features (either enhancements or epics) and can be tracked using Microsoft Excel or an enterprise agile software tool. Now you know the Who, What, When, Why, and How of agile requirements; what are your thoughts?

Agile Requirements – The Who, What, When, Why, and How?

Tags

, ,

We’ve all heard the statement, “Agile doesn’t need requirements;” well, that is not true in the health care, insurance, financial and other industries. At the heart of software development are the requirements; if there are no requirements, how are the developers creating the new product? When is Done, Done! Typically, a business analyst (BA) elicits the business and non-functional requirements. According to the International Institute of Business Analysis, a “business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.”  According to the Bureau of Labor Statistics, 876,000 business analysis related professionals will be needed by 2020. This is seen as a vital role and based on current trends, is not going anywhere. With the growth in Agile project and software development, the role of the BA is more important than ever. However, how the BA fits in the agile framework is still a mystery. Agile Requirements Elicitation (ARE™) is a framework that identifies the Who, What, When, Why, and How of requirements elicitation.

The Who

The Who is the business analyst. The BA owns, or shares, responsibility for user story driven development, whole team approach, team change management, sprint risks/issues, and sprint communication.

The What

The What is creating the user stories. User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

‘As a <type of user>, I want to <some goal> so I can <some reason>.’

Within the description of the user story, the business analyst may choose to write bullet points describing functionality or may include process flows if the functionality is complicated or requires validation. According to Cohn (2011), user stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.

The When

The When is typically before Sprint 0. This is when the BA is continuously working with the Product Owner to identify the new requirements and creating the basic skeleton and plumbing for the project so that future sprints can truly add incremental value in an efficient way. It may involve some research spikes. The BA is also grooming the backlog, adding, removing, or revising requirements based on the additional knowledge obtained from the product owner, his/her wants becoming  clearer. In ARE™ this work can also be performed in sprint -2 or sprint -1. These are sprints that occur while the development and test teams are working on the current sprint and as we know, changing the scope of the current sprint is not recommended.

The Business Analyst is responsible for leading the project team and service areas through release planning session activities up to the 1st release only to keep the team focused, which will be broken down into one – to – many sprints or iterations.

The Where

The Where is the Product Backlog. According to Cohn (2004), the agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it’s not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers. According to Prakash (2013) the product backlog is a living document. Stories are added, modified, and split into small ones all the time. The backlog can be created during project initiation. From then it grows and is refined as needed. There should be a few stories in the product backlog at the time of Sprint Zero’s start, enough to help the project team demo at least one working feature.

The Why

The Why is requirements engineering. According to Sommerville (2004), requirements engineering is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. Requirements engineering and its deliverable, requirements, are inevitable and serve a dual function (1), may be the basis for a bid for a contract – therefore must be open to interpretation; (2), may be the basis for the contract itself – therefore must be defined in detail; and (3), both these statements may be called requirements. So for contract work, requirements are needed to proof that you have delivered the necessary functionality to your customer and/or product owner.

The How

The How is ARE™. ARE™ is an agile process that is specifically geared to eliciting requirements for disciplined iterative project delivery (DiPD™).

A feature is requested by the product owner and the BA creates an enhancement or an epic. The BA, or PM, or Scum Master, can then prioritize the new item qualitatively (high, medium, low). The BA adds the requested enhancement of an epic to the backlog and works with the product owner to groom the backlog. As part of the grooming activity, the new enhancement or epic is either deemed not fixed, which means it won’t fix a defect, deferred, which means moved to a lower priority in the backlog, or needed and is then updated. The BA works with the product owner to refine the enhancement or an epic while the BA create stories for the enhancement or an epic. Once the user stories are created, the BA presents them to the project manager, Scrum Master, and Dev/Test/Design team leads to obtain their feedback. If wireframes are needed, the BA begins to create them; the product owner approves them; and the user stories transition to the manage sprint stage.

In sprint 0, the BA works with the PM, or Scrum Master, to coordinate sprint planning. This is typically 2 weeks, but can be more. The BA creates a release or sprint requirements package, which is the product backlog which contains a list of the user stories planned for the release and/or sprint approved by the product owner. The user stories are reviewed and discussed with the Whole TeamSM and decomposed into tasks, sized, estimated, and owned by the Whole TeamSM. A sprint duration can last between 1 – 4 weeks; but at the end of the sprint, a demo is presented to the product owner and if approved, the team moves the working code to the transition and/or hardening sprint(s) that is the predecessor to deployment.

In the prioritized stage, new enhancements or epics are discussed amongst the product owner, project manager, Scrum Master, and Dev/QA/Design team leads for better understanding and are categorized in the product backlog as ‘Won’t Fix’, ‘Deferred’, or needed and then given a priority. An estimate is given by the Whole TeamSM using planning poker, or some other estimation game. The estimate is added to the enhancement or epic, or is deemed unestimatable. Once approved, the estimate is added to the upcoming release/sprint scope by the project manager,  Scrum Master, and business analyst.

The End

As you can see, the BA’s role is more collaborative and as important in agile software development and agile project management as it is in the traditional software development word. Requirements are needed and can be used in agile; the format is not a word document, they are just-in-time requirements. The requirements are features (either enhancements or epics) and can be tracked using Microsoft Excel or an enterprise agile software tool. Now you know the Who, What, When, Why, and How of agile requirements; what are your thoughts?

Look to this blog for more agile topics, tips, and ideas. Gsmithcsp.wordpress.com.

State of Scrum – 2013 Response

Tags

, , , , , , , , ,

Recently the Scrum Alliance released a ‘State of Scrum’ study to its members and general public. The report is based on an extensive survey of nearly 500 participants from more than 70 countries. The goal of the survey was to understand the current “State of Scrum” using the 800,000+ members of the Scrum Alliance, ProjectManagement.com, and ProjectAtWork communities. I will use this blog to highlight data points and provide my thoughts.

  1. 54% either agree or strongly agree that a certification such as a Certified Scrum Professional (CSP) improves their chances of sustained SCRUM success.
  2. Culture is king in the agile world and organizations must create cultures that encourage collaboration in order to deliver value to their customers.
  3. Scrum is the overwhelmingly preferred agile method used by 40% of the respondents, followed by Kanban, 15%.
  4. 41% of respondents feel that fulfilling customer needs is highest.
  5. 34% of the respondents felt that Scrum was successful on at least 75% of the projects for which it was deployed

Point #1: Whether you are a proponent for certifications are not, in my opinion, training and certification is needed in order to successfully lead a scrum team for this reason; typically, scrum projects are started as skunkworks with little guidance. If you have the training you know how to handle the unexpected, know how to build your scrum team, and know how to communicate up and down the organizational hierarchy. Certification lets the team, management, and others know that you professional and are skilled in your craft. I also realize that experience is also needed to be successful, but training and certification tells me that you are committed to the craft and you finish what you start.

Point #2: One overlooked and underestimated item when starting a scrum project is the need to account for organizational change. I have seen many a project fail due to inattention given to this item. Very little occurs in a corporate organization without management knowledge and approval. Agile, if performed correctly, will force the organization to examine itself and make organizational changes for the better. Having executive support can ease the changes and it will also give you a place to discuss issues, impediments, and make continuous improvement suggestions and acknowledge Whole™ team success.  Referring back to point #1, training and having certified team members will give you a roadmap on how to begin the agile transformation that will lead to you effectively managing organizational change.

Point #3: I was not surprised to read the results of Scrum being the preferred Agile method because one, it focuses on collaboration and planning; two, it is very easy for a team to pick up and learn; and three, it focus on the customer. Scrum will continue to grow [in popularity and use] because it is poised for the “Age of the Customer.” Having a product owner who is actively engaged in the project can lead to a successful project provided that product owner has been trained in Scrum, is passionate, knowledgeable, willing to collaborate, and be a servant leader.

Point #4: In leading an agile transformation for a Fortune 26 company a day did not go by where the team did not ask how does this fulfill the customer’s needs when a new requirement was identified, when a user story was written, when development was started and when testing was initiated. A focus on the customer is paramount when working on scrum teams. Having a product owner heavily involved gave the project credibility and using Scrum enabled the product owner to provide the necessary guidance.

Point #5: I agree with point 5 with a few caveats. One, this will be difficult to achieve it the scrum team is being managed in a command and control way. Servant leadership must be employed. Two, the maturity level of the team has to be at the performing stage (Tuckman Model®) in order to delivery consistently. Three, the PMO must be involved to provide guidance and implement continuous improvement measures that are beyond the scrum team’s ability, organizationally. For example, if a scrum project is working in a service-tiered organization that team will perform well until it needs to go outside itself for things that are performed outside the core team (e.g. infrastructure). Success will be at its greatest when all team members, core and non-core, collaborate together in delivering a product that meets the customer’s expectations and can plan and solved their problems together.

My final take on the survey is this, for an organization to begin to realize the benefits of agile they need to have a servant leader PMP®, PMI-ACP, or CSP® managing the project through a PMO, have executive support, exist in a large revenue generating company where SCRUM training is provided to the Whole™ team and have a product owner. This will be the roadmap for prolonged success.

What do you think, go to http://www.scrumalliance.org/why-scrum/state-of-scrum-report, download the report, or watch the video, and respond to my remarks. And remember, Agility…Iteratively™! MJS

Moving to Agile in a Waterfall World – A Story of Agile Adoption at a Large Grocery Retailer

Tags

, , , , ,

Opening Quote:

“Ambition is a very pretty thing; but sir, we must walk before we run.” 1851 G. Borrow Lavengro II. ii

This truism applies to many areas of life and is highly appropriate for large organizations when attempting to adopt agile within a traditional software development environment (aka waterfall). This article explores what transpired when a large retail grocer invited a team of agile experts from a service vendor to partner with them to develop an enterprise agile transformation program that would fit their existing corporate culture. The program would pilot a newly devised agile delivery framework that would provide pragmatic, realistic measurements that will evaluate the effectiveness of the agile practices on the company’s software development projects.

The retail grocer, headquartered in the Midwest (USA), is one of the nation’s largest grocery retailers, with fiscal 2011 sales of USD90.4 billion; spanning many states with grocery and multi-department stores, convenience stores and mall jewelry stores.

Software development is a critical part of grocer’s business model today and in many regards has become viewed as a competitive advantage for the company.  Over a four year period, the grocer embarked on a strategy to improve its’ software processes, to move away from a siloed-tiered IT organization to a service-tiered organization where infrastructure and enterprise wide IT resources were grouped into a set of shared services.

In addition, the application development function was further re-organized by functional area (grouping Project Management, Business Analysts, Enterprise Architecture, Software Development teams, etc. into discrete teams) where line managers were replaced by resource managers responsible for staffing and employee evaluation.  Finally, all capital projects were required to adhere to more rigorous project controls.  Unfortunately, these changes failed to achieve the desired results at the grocer.  After a four year journey, teams were struggling with collaboration, product quality had not improved, and project delivery stood at 59% and project timeframes continued to average 30 to 41 months.

Admittedly, the company’s waterfall development approach worked well for projects that had a well understood timelines, domain space and technology, but often failed to meet business expectations in newer, innovative areas.  In general, the grocer’s application development teams struggled to deliver value quickly, and most projects ended up costing more than expected and consumed unplanned resources.

The grocer’s journey of agile adoption started long before they ever engaged a service vendor for assistance. Experimenting with agile, several IT resources obtained Scrum Master Certifications and started piloting agile practices but ran into a variety of implementation difficulties which resulted in the grocer’s leadership defaulting back to their traditional development approaches as the “least risky option.”  They cited several failed attempts to adopt agile practices in the past due to a lack of:

  • appropriate transparency and visibility within the agile projects
  • inability of agile teams to “stick to a plan”
  • any meaningful measures/evidence showing that agile projects out performed waterfall projects

Regardless of these initial results, some members of the software development community felt confident that agile practices could indeed be successful at the grocer given the right level of planning and modification based on the company’s unique requirements.  Knowing that a large multi-national service vendor had itself been undergoing an agile transformation initiative, the grocer’s delivery effectiveness team sought the counsel of the multi-national vendor services organization for assistance with their agile adoption.

Working with the grocer, the service vendor evaluated their software development practices to identify scaling factors that could be preventing the successful introduction of agile practices.  They determined that practices such as Scrum and XP could be effective on agile projects, but would require significant modification.  The service vendor’s Agile Scaling Model was used as a reference point to determine how to effectively adapt and scale classic agile practices. During an assessment of the grocer’s environment, the service vendor’s team discovered that the following scaling factors affected most of the large software development projects within the company:

  • The development teams were relatively small but geographically distributed across various locations;
  • The retail grocer had specific project / governance disciplines that must be followed;
  • Project environments required the support of many operating platforms, including legacy environments;
  • The product domain was innovative and rapidly changing;
  • The retail grocer’s organization was highly distributed, involving multiple internal organizations and independent third parties; and
  • The retail grocer’s organizational structure was quite rigid and steeped in existing procedures and practices

Enterprise transformations are difficult at best in large enterprises such as the grocer, and they typically require a gradual and phased adoption strategy that permeates the organization over a period of time. Armed with this organizational insight, the grocer realized that they would not be successful with a haphazard approach to their agile adoption.  Instead, the grocer put in place a deliberate and strategic agile adoption plan based on a hybrid delivery model that applied an iterative and incremental approach to agile transformation based on a common set of guiding principles:

  • Maintain a focus on business value / results
  • Drive the vision for adoption from the top-down and implement from the bottom up
  • Adopt agile practices iteratively in waves
  • Adapt quickly and embrace new practices as projects and teams mature
  • Strive for quick-wins and modify accordingly based on lessons learned (retrospectives)

The grocer’s delivery effectiveness team divided their multi-year agile transformation program into multiple waves, each lasting approximately 9-12 months.  Each wave of their agile evolution would require commitment and action at multiple levels within the organization.

During Wave 1, the grocer’s delivery effectiveness team set several goals:

1)  Assess the organization to identify the current state (current software practices, scaling factors and organizational challenges that could impede their agile adoption),

2)  Define an initial agile framework to pilot in conjunction with their traditional process

3)  Create a set of criteria, or decision matrix,  to identify agile-friendly projects, and

4)  Conduct an agile pilot using a “real-world” capital project to measure the effectiveness of the agile practices and the grocer’s adoption strategy.

In subsequent waves, it was planned that the service vendor and the grocer would use feedback from the Wave 1 results to update and adjust the grocer’s agile adoption strategy, agile framework, and decision matrix, as necessary, and would conduct additional pilots to expand the program in different areas of the both the business and IT. Given the organization’s previous issues with Agile, and more specifically, Scrum, and given the complexities inherent in the grocer’s software development projects, the grocer decided to implement a Disciplined Agile Delivery Framework and apply the service vendor’s Agile Scaling Model, two methodologies that were created and espoused by Scott Ambler, chief agile methodologist for IBM Rational®. Disciplined Agile Delivery (DAD) is defined as:

… an evolutionary (iterative and incremental) approach which regularly produces high quality solutions in a cost effective and timely manner via a risk and value driven life cycle. It is performed in a highly collaborative, disciplined, and self-organizing manner within an appropriate governance framework, with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders to maximize business value provided. Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.

The Agile Scaling Model (ASM) is a contextual framework for effective adoption and tailoring of agile practices to meet the unique challenges faced by a software or system delivery team of any size.  There are a several scaling factors that address a wide variety of agile bottlenecks, including but not limited to, geographic distribution, regulatory compliance, technical complexity, and others.

Using these scaling factors as a guideline, the service vendor conducted an assessment where the following scaling factors were identified:  geographic distribution, enterprise discipline, problem domain, project complexity, and organizational structure.  Based on the existence of these scaling factors, the grocer’s delivery effectiveness team implemented the following agile practices:

  • Risk Value Life-cycle
  • Release planning
  • Whole Team
  • Shared Vision
  • Business Value Focus

Scrum is an agile project management framework which works in conjunction with other agile practices to provide teams with the following capabilities:  time-boxed iterations, product backlogs, user stories, sprint plans, daily meetings, sprint demos, and sprint retrospectives, so teams can build and deliver small chunks (iterations) of “potentially shippable code”.  DAD expands the Scrum life-cycle by incorporate the entire software delivery phase, not just focusing on the software development organization.  DAD acknowledges that the development team is dependent on other critical enabling organizations (verification testing, integration testing, IT operations, etc) in order to get its software into the hands of customers.

While the grocer’s first wave of agile adoption was deemed as a success, it wasn’t without its challenges. Moving to a Disciplined Agile Delivery framework was a big adjustment for the pilot team.  Culture wars ensued where some team members wanted to continue with “business as usual” (i.e. maintaining traditional practices) while other team members wanted the flexibility to use Scrum techniques “out of the box” with minimal coaching.  Change is painful, and all of these issues had to be overcome gradually.

Like any large organization, the grocer continues to struggle with ongoing agile adoption issues, including:

  • Organization Structure: the grocer has a three-tiered service model which has constrained their ability to create “cross-functional” agile teams due to the strong established roles. The company is still working through organizational changes to facilitate an agile process.
  • Project Funding Model: The front and back ends of the grocer’s software development life-cycle still practices Waterfall processes, which limits the ability to do rapid software development iterations.  For example, approval of projects occurs twice a year, and projects must come to within +/-5% of total funding to gain approval which requires that ‘all’ of the requirements and design activities are completed.  The grocer recognizes the need for a more flexible funding approach to fit with a development model of more frequent development iterations.
  • Internal Governance: The grocer’s Project Management Office (PMO) was not initially involved in the company’s Agile transformation and resisted it, but there is a recognized need for the PMO to be more engaged as a facilitator and enabler of an Agile process across the software delivery life-cycle.
  • External Governance: The grocer is required to conduct end-to-end testing of their solution and submit it to a third party for a two week validation period before the product changes could go into production.  This governance must be incorporated into the overall Agile process to get software quickly into the hands of internal and external customers.
  • Team Dynamics: During the iteration planning meetings, the team struggled with understanding the value of  estimating using story points and iterations with the extended team (people who are not part of agile pilot [core] development team).  Secondarily, the story points needed to be converted to an hours based system where a final budget can be calculated for the project.  Success with Disciplined Agile Delivery will mean the incorporation of an expanded group of stakeholders who are responsible for overall software delivery.
  • Estimating Effort: The grocer is refining its Agile practices in the areas of estimation, including grooming the product backlog, conducting sprint planning as story points, and using Agile measurements such as velocity and release burn-down charts, product owner acceptance, total test cases planning and executed, and total number of defects.
  • Use of Agile Planning Tools: The pilot team expressed frustration that there were “too many tools” involved in getting their job done. The tools the team did have access to were not being used effectively. The service vendor and the grocer have piloted the use of an enterprise agile project management tool to help manage the product backlog and improve team collaboration.  The grocer pilot team team continues to struggle with what is the right set of enabling tools to manage their internal agile software development activities as well as those with an external third party vendor.

The grocer’s first wave of agile adoption achieved several benefits as a result of an enterprise adoption framework and the incorporation of disciplined agile practices.

  • The increased collaboration between the Product Owner and IT led to higher business satisfaction, greater levels of organization trust, and better overall planning.
  • The project was able to consistently deliver business value more rapidly than when the team was using waterfall – with at least a 4 times increase in the frequency of development releases compared to a traditional [waterfall] process.
  • The project team delivered software that was closers to the product owner’s satisfaction and released higher quality products while receiving more frequent feedback from their key stakeholders.

The grocer’s story is a classic example of a company that was steeped in traditional [waterfall] software development processes that is now achieving incremental success and tangible results by incrementally adopting agile practices.  Despite the real and ongoing technical and cultural challenges, the pilot reported measurable, positive outcomes in the delivery of working software which will have a measurable impact in driving additional revenue. In the grocer’s case, the organization simply had too many complexities to adopt Scrum in its purest form.  By adapting agile practices in line with the grocer’ scaling factors (organizational complexity, governance, functional roles), the grocer was able to attain significant improvements in product quality, speed of delivery, and increased customer satisfaction that were unattainable in their previous attempts at agile adoption.  For the grocer, a Disciplined Agile approach was the only path towards success.

Closing Quote:

“Enterprise Agile Adoption is a marathon, not a sprint.” Gerald Smith, CSP, PMP