Adding Points to Defects

Tags

, , , , ,

According Pund (2013) during sprints, there are defects that are identified and have varying severities, and the [Scrum] team must make decisions to “fix in the sprint” or “push to the product backlog.” This is typically decided based on whether the developed user story still delivers business value. If a defect prohibits the execution of the functionality, thereby rendering zero business value, is not fixed by the [Scrum] team by the end of the sprint, the Product Owner will not consider the story points “delivered” and the story will not be “done.” The [Scrum] team’s goal should always be to minimize the amount of defects and several ways this can be accomplished is by collaborate with the business analyst’s to understand the requirements, collaborate with quality assurance lead to understand how the testers on the [Scrum] team are planning to test the functionality, and the developers on the [Scrum] team perform unit testing and shares those results with testers. When estimates are determined, rework (e.g. defects associated with the user story) should be included in the estimate for any user story, and is included in the story point estimate. However, there are defects that are identified that are not linked to a particular user story; for those defects, I suggest creating a “feature development” user story for each sprint, providing a story point estimate to it and linking those defects to this user story. An example of this is a defect where a query is CPU intensive. This defect was identified in production and is not linked to a user story the team has accepted into a sprint. This will require [Scrum] team resources to resolve and the team has resolved it. The original estimate was 17 hours and the actual hours was 5. OR another defect where a customer was unable to place an order on the website. The root cause was a data issue. The original estimate was 6 hours and the actual hours was 5. How are either of these defects calculated in the team sprint velocity if user story points are not assigned? I suggest creating a “Application Defect” or “Internal Work Request” user story for each sprint, providing a story point estimate to it and linking the aforementioned defects unrelated to in-scope projects, to this user story. This enables the calculation of sprint velocity for the [Scrum] team; tracks the amount of defects that are identified outside of approved in-scope project work, and allows the team to proactively address defects that are raised in production that may require immediate effort to resolve.

Your thoughts?

Bibliography:

Pund, Prashant (2013). Should Defects Be Considered User Stories. Retrieved from https://www.scrumalliance.org/community/articles/2013/2013-may/should-defects-be-considered-user-stories.

Servant Leadership

Tags

, , , , , , , ,

I’ve been having this ongoing conversation with a college of mine where we discussed the topic of servant leadership. After sleeping on it, he arrived to the office the next day and asked me the following: Isn’t servant leadership …leadership? I replied, yes, but a different type of leadership. Now, the context; our conversation revolved around servant leadership, by project managers, in a traditional waterfall or agile project. His point was – he supports his team by removing constraints, holding weekly, sometimes daily, status meetings; and creates ‘widgets’ for SharePoint that track team milestones, defects, version control, and other activities. He then states that he ‘enforces’ dates for completing milestones on his team and ‘pushes’ his project teams to meet those dates, if not, he works to de-scope the items that will not make a milestone out of his project. My point to him was that “this is not servant leadership.” Servant leadership is about trust: trusting your team to get the work done they committed to. Serving them by protecting them from meaningless meetings, removing constraints they encounter; providing them with the decisions needed to complete their work; and growing them into a empowered, confident, efficient , and predictable team! In Scrum, the Scrum Master, in this case, an agile project manager (APM), is responsible for ensuring Scrum is understood and enacted. Scrum Masters, or APMs, do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master, and APM, is a servant-leader for the Scrum Team. The Scrum Master  and APM, serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Teaching and leading the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood

Robert Greenleaf writes servant leadership is a management philosophy which implies a comprehensive view of the quality of people, work and community spirit.” Although my colleague supports his team by removing constraints he also does not coach, teach, nor has a project management philosophy that views the quality of people, work, and community. As soon as I told him that trust is a key to agile project management success, he stopped talking, thought a minute, and then said “Isn’t trust coming from the way the project team communicates to business leaders, sponsors, and stakeholders?” My reply “trust comes from when the project team can meet their commitments consistently and become predictable.” “Once the team becomes predictable, the business leaders, sponsors, and stakeholders will increase their support of the team and they will become proxies for the [agile] project manager and Scrum Master. In short, as agile practitioners we need to continue to practice what we preach, educate those who are learning the agile way, and support those as they mature in their learning and practice. As Mahatma Gandhi once said, “Be the change you want to see in the world.” In the case or project management, “be the servant leader you want others to be.”

Agile Project Management Tool, What to use and When

Tags

, ,

I attended a monthly Agile Professional Development chapter meeting last evening in Dayton, Ohio. It was the second such meeting to occur (hats off to Sam O’Brien who organized it). It was attended by developers, business analysts, scrum masters and newly minted professionals (newly minted is defined as my company is doing agile and I’m it)! A topic of conversation was this, which project portfolio management (PPM) tool does your company use? Several in the room said they are using Microsoft TFS, Microsoft Excel, IBM Rational Team Concert, others are listed here. I was struck not by the use of the tool, but by the diversity. If you talk to professional project managers in software development and ask them which tool they use you’d get one of two responses, Microsoft Excel or Microsoft Project. Not to go down the track of comparison and contrast; but, more importantly, the conversation shifted to when to introduce a tool. Several in the meeting suggested not to use a software tool but use an information radiator (more on that later). I shared a story of introducing a tool tool soon to a scrum team I was coaching and the team revolted! The tool was ‘forced’ on the team without their request (a no, no) and after training (1 day), they were off and running. Performing their work on the iteration while learning a new tool was not an easy thing to do. Obviously they had problems using the tool, which impacted productivity, and these problems were discussed passionately during the retrospective. My lesson learned, make sure before the team uses a software PPM tool they are proficient in using more traditional agile tracking tools (information radiator, burn down and velocity charts, product/iteration backlog, buildup charts, etc.) and events (daily scrums, sprint planning, sprint reviews, etc.). And most importantly, make sure the team asks for a software PPM tool to use. This will alert you to the team’s growing self-sufficiency, maturity, and willingness to be transparent. This will also save you a ton of headaches and I told you so! Your thoughts?

Agile and Microsoft Project, Yeah Right!

Recently, I had a conversion with a project manager (certified or not, it doesn’t matter) and he was asking questions in a department meeting concerning agile. The topic that prompted his questions was in response to a request to have PM artifacts that can be used on agile projects. That is code for how can we have the project managers create a Microsoft Project (MSP) plan and give it to managers and senior leaders. One of his questions was how can a project manager use MSP for agile? In responding to his own question, he stated that it cannot be done and it is counter-productive. My name was thrown in as a person who provided a MSP template that could be used as an agile template. Some context, I was responding to a request for an agile MSP template and I just happened to have one J

During the conversation, the project manager that asked the question, once hearing this, turned to me and mouthed, you actually used an MSP plan for an agile project? And it worked? After the meeting he followed me to my desk and I showed him the template. The link to what I created is here: http://www.mpug.com/articles/creating-an-agile-schedule-with-ms-project/. Many thanks to Vincent McGevna and MPUG. I used to be the president of the Greater Cincinnati chapter in the early 2000s. Now, after discussing uses of the template and agile in general, he told me about his experience. He managed agile projects where there was no product owner, Microsoft Team Foundation Server (TFS) was being used, and the project team gave sizes (T-shirt) and resisted provided daily updates. Oh, they had daily scrums, but they did not want to provide the project manager their hours worked that day. They were on 2-week sprints and sometimes they had demo.

Now, I know agile purists will say a software tool should not be used and there needs to be a product owner, scrum master, and daily scrums with progress (in hours) added to the index card on the information radiator; and I somewhat agree. I would add and counter that if you are in a company doing agile and there is no product owner, or proxy, then you are NOT doing agile! If you are in a company doing agile and there is no information radiator visible to the project team  then you are NOT doing agile! Where I will differ, if you are in a company doing agile and you are using a software tool, MSP, Microsoft Excel, TFS, then you COULD be doing agile. Companies are increasing moving toward agility and by necessity will want to try to cram agile into their bureaucratic, document heavy, command-and-control environment. Don’t fret, remember, moving toward agility is an iterative process where you need to incorporate organizational change management concepts. For example, if you are asked, or told, to use MSP as an agile tool, use it; however, make sure you create an information radiator that is visible to the team. Lead the team in iteration/sprint planning where user points are obtained and place them in your tool. Focus more of serving the team and use the tool to support you instead of other way around. In Microsoft Project 2013 you can create a burndown chart . Earlier versions of MSP will create a burndown chart for you but in Microsoft Excel format (e.g. http://blogs.msdn.com/b/project/archive/2007/11/14/we-re-back.aspx). Using Microsoft Excel files can perform the same thing as well as well-known tools.

Regarding the missing product owner, if a product owner, or proxy, is not available I would question is agile the right approach to use for the project. Who will answer the teams questions on the user stories; who will attend the demo and comment on what was product; who will groom and prioritize the user stores, epics, themes in the product backlog, the project manager? For that matter, who will create the user stories, the project manager? If you answer is yes, then you are NOT doing agile. You, my friend, are doing waterfall masking in aa agile costume.

Getting back to the project manager in question, he started to denounce the use of a software tool, Microsoft in particular, and continue to go on about how success using the software tool will not work in his environment. Remember, the goal isn’t to win an argument but to take the opportunity to teach and educate.  Agile software development, and agile project management, is still in its infancy in corporate America and in order to gain converts, you must show them the path and have patience in their pursuit to agility while you guide them to the light! As I’ve always stated, move toward agility…iteratively™.

What do you think?

Leadership in a Hybrid IT Culture

Tags

, ,

I am writing this to discuss the role of leadership in a hybrid culture. Hybrid means, in a project management sense, that IT departments are using a combination of waterfall and agile software development methods to delivery projects. Some call this Agil-Fall or Water-Agility; regardless of the term, what is needed is leadership, whether that is from the agile project manager, developer, tester, or product owner. I have been in IT department where employees have been employed for over 20 years and have the absolutely refuse to lead. Leading is not being knowledgeable about a system, process, or tasks. Leadership is understanding what needs to be done and collaborating with those that it impacts and leading them to resolving the issue, problem, or task. I have worked with very knowledgeable people who will not, nor ever, lead! They can tell you what to do but in the next sentence, say…We Need a Meeting To…

Leadership does not require a meeting. Leadership requires knowledge, fearlessness, humility, and accountability. Knowledge in knowing what is required to complete a task; fearlessness, by involving others so they can work together as a team, even if you do not like that person(s) and even if that means they disagree with your approach and come up with a new approach. Humility in realizing that your approach is not the best one and you support what the group decides; and accountability in holding yourself, and others, responsible for getting it done. Unfortunately, in several IT departments, they are devoid of leadership. From senior executives to hourly employees. We have become culture of kicking the can down the road for someone else to work on or pointing fingers when something doesn’t get done…even when we know what needs to get done.

One of the things I like about Agile is that accountability is inherit in the process. It is very hard to point fingers when you meet daily to give an update on your work. It is very hard to kick the can down the road when you’re the one responsible for completing the work and you know others are dependent on you. Employees need to be empowered to solve their own problems, learn from their mistakes, and hold other employees accountable. Managers need to become more servant in their leadership in support of their direct reports. Leaders are made, not born. Leadership is therefore cultivated, not granted! Your thoughts?

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?

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