Why is Hybrid Agile Such a Bad Thing? The Secret Is That It Really Isn’t!

Tags

, , , , ,

With the movement toward agile software development and agile project management; and with all the training available from certified scrum trainers, agile certified practitioners, and product owner, and with the move of software development to near-shore and off-shore location; why isn’t there any training on how to transition a scrum team from one location to another and more importantly, why does a hybrid agile approach seem so bad? The perception is that if you are not using “pure” agile then you are prone to fail in your attempt to utilize agile to achieve all of its benefits.

But there are times in organizations that leadership decides to go in a direction that is in direct opposition to the agile manifesto and the twelve agile principles. What is a certified [agile] project manager to do? Complain about the lack of “pure” agile commitment? Become a martyr and work against the interests of leadership? No, what a certified [agile] project manager would do is find a way to incorporate the best practices of the project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way.

The agile team decided to use scrum as a framework but with caveats. We had to incorporate approval gates and work with a project management office where I was required to provide status updates, manage change, and obtain approval for budget and release management. This resulted in a hybrid agile approach called DiPD®, Disciplined iterative Project Delivery®. The iterative framework is typical of any scrum development workflow with a few exceptions. One, I did not release at the end of every sprint; two, I needed approval to move from project intake to release; and three, I used documentation.

Starting with the product backlog, also known as a work item list. It contains uniquely ranked stack of user stories so the team can focus on delivering valuable functionality. The ranking of the user stories aids the business stakeholders to decide which functionality is more valuable than others (e.g. MVP1, MVP2, etc). Having MVP2 user stories in the backlog that are not being worked on is acceptable and means the team hasn’t gotten to them yet. User story dependency is included so the team doesn’t work on a user story too soon; this prevents work disruption.

Project Scoping Current State (Business Ideas)

This is important to our team for the following reasons:

  • First time our team is made aware of the entire project.
  • This is formal notice given to our team to proceed with maturing the Project.
  • While change requests have the business needs defined, they do not include all the assets necessary to build out the solution.
  • This introduces the project to the larger team so they can become aware.
  • This identifies dependence among user stories which aids the Product Owner in aligning the Project for future sprints and releases.
  • It provides a high-level estimate of effort of business decision can be made.
  • This is the formal handoff from our team to our client of the analysis performed.
  • Business has the opportunity to resubmit or stop the project.
  • This formalizes the project into executable work for future delivery.

This is where our team provides the estimates, acceptance criteria, and user story dependency back to the Product Owner, and where our client can approve / reject / hold the change request.

 Epic and User Story Maturity (Product Backlog)

This is important to our team for the following reasons:

  • The business analyst works on only approved projects.
  • The Scrum Master can provide awareness of the approved user stories with each of the teams.
  • The Scrum team members have vetted the general requirements and posted needed questions/clarifications ultimately back to the Product Owner for maturity.
  • The content of user stories is complete; all questions/clarifications have been made; and all acceptance criteria are adequate for development and testing to successfully deliver.
  • The Scrum team members understands how to approach the testing of the user stories’ functional and non-functional aspects.

This is where our product backlog is built with a goal of keeping it healthy so work can be continually ‘pushed’ to the team.

 Acceptance (Sprint Backlog)

This is important to our team for the following reasons:

  • Allows our team to fill out sprint capacity.
  • Allows our team proactively make adjustments to sprint work due to changes in resource availability or prioritization.
  • Sprint and release placement aids our client in knowing when an approved project are planned for release.
  • Our client can notify their Partners accordingly.
  • Their Partners can begin assigning resources UAT.
  • Our team is able to ready the approved project and user stories for sprint planning activities.
  • Our team is able to provide a sprint roadmap to the team.
  • Our team is able to provide a release roadmap to LE.
  • Our client is able to realign partner priorities and communicate expectations.

Our client and our team are able to baseline the sprint

Approval Gates (PMO)

Agile, by its nature does not have approval gates. However, in all of the companies I have worked, I have never been able to deploy code to a production environment without having to obtain some level of approval. So in reality, there is an implied approval that has to be obtained before moving forward with a deployment. There are mandatory approval gates my team must adhere to as work moves from idea to working code in a production environment.

This is important to our team for the following reasons:

Gate 1: Defined business ideas

  • Our client is able to filters unviable projects from coming to our team.

Gate 2: Estimation approval

  • Our client determines if business case is relevant based on estimates provided.

Gate 3: Backlog maturity

  • Our client reviews functional solution for MVP and determines if the solution is supporting business need.
    • Our client needs to understand what they are signing off on so it meets the business need preventing rework and future story creation.
    • Our client needs to plan UAT, engaging their partners, aligning external parties around the functionality that is being defined.

Gate 4: Sprint planning

  • Our client defines the priority of work among all projects.

Gate 5: Sprint demo

  • Our team and our client signoff on expected work, the sprint increment, in accordance to quality requirements.

Gate 6: Our client provides our team with release approval.

Both our team and client are assured that modifications work as expected in the end-to-end environment and decides whether work will be released

The Results

There is a lot to like about the DiPD® model. For starters, I was able to increase scheduled release frequency, year over year by 45%. I was able to increase scheduled out of cycle releases year over year by 300%. I was able to add and train a second scrum team using the DiPD® framework and deliver a digital download platform that had failed in a larger company, in 7 months. And finally, I was able to successfully transition development from the U.S. to Bangalore, India in 4 months. There is still a lot of work to do but the hybrid framework is working for my team and my client. And remember, quality is not what you or I deem it is; quality is what the customer deems it is. Specifically, when a product of service completely meets a customer’s need, quality is delivered (PMBOK®, 5th Ed.).

To close, using a hybrid agile software or project management approach isn’t a bad thing. With the challenges facing companies today, following any framework to the letter is a huge risk. You need to incorporate the best practices of project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way. Move to pendulum from bureaucracy to agility…iteratively™.

Advertisements

Product Owners – The Project Sponsors

Tags

,

Too often in agile communities across the corporate spectrum, the majority of the focus is on the agile manifesto, agile framework, agile team, or agile development and testing strategies. Little attention is paid to the agile Product Owner. This paper will describe the importance, and practicality of the role in a realistic agile environment.

According to Mike Cohn’s book, Agile Estimating and Planning (2006), the primary duties of the Product Owner include “making sure that all team members a pursuing a common vision for the project, establishing priorities so that the highest-valued functionality is always being worked on, and making decisions that lead to a good return on the investment in the project.” Cohn (2006) continues in that “the second role of the Product Owner is that of customer.” “The customer is representative of a group or division” that is responsible for providing direction, prioritization, and decision making in support of the development the agile team is performing so a valuable product is built and launched for use by the community, (either a paying public or internal company users).

On the projects that I have worked on there have been strong and weak product owners; effective and ineffective product owners; or engaged or absent product owners. I have also observed that there are no two alike Product Owners. Each Product Owners brings with them their own thoughts, ideas, opinions, micromanagement; and they are always wanting to dictate what gets worked on, when it gets worked on, how it gets build, and how quickly it can development and completed.

The Product Owner role in agile is important because they are needed to do the following:

  1. Be the receiver of new product ideas and enhancements.
  2. Effectively manage constantly shifting business priorities.
  3. Effectively convert business valued product ideas and enhancements into business requirements.
  4. Transfer those business requirements into change requests epics and user stories.
  5. Effectively prioritize and provide guidance to the agile team building the software product.
  6. Willingness and knack to make decisions in moving the agile project forward.

Decisions made by the Product Owner are not made in a vacuum, they are made with the Agile team, business stakeholders, line-of-business and other individuals. Decisions have to be made so team progress can move forward, closure and acceptance of past sprint work can be performed and obtained, and old issues remain in the past. Additionally, Product Owners need to resist the following:

  1. Do not become a bottleneck. The Product Owner needs to make themselves available. If they cannot, have a Product Owner proxy, someone that can fill-in for the Product Owner when they are not available; they are knowledgeable about the system, business and backlog, and is empowered to make decisions.
  2. Do not be the architectural owner. The Product Owner should be the person who has the final say over the work prioritization decisions and not the technical direction. Combining the two leads to chaos and confusion.
  3. Do not lead the agile team. The team is self-led, self-empowered, and are coached by the Scrum Master, not the Product Owner. The Product Owner needs to available to the agile team as much as possible; to have a solid understanding of the business domain and the needs of the business stakeholders.
  4. Be a skilled negotiator. Many large projects have competing and mutually exclusive needs, as well as differing views on priorities. Those large projects also have many requirement and sub-team dependencies. The Product Owner needs to make themselves aware of the priorities and dependencies and be capable of speaking to anyone in the organization as priorities shift; risks have occurred, and maintain stakeholder expectations.
  5. Support and Protect the Agile Team. The Product Owner needs to be a proponent of the agile team, they need to aid the Scrum Master in protecting the team from errand business requirements, differing priorities, and quickly resolving issues that constrain or block the agile team from doing their work.

In summary, Product Owners is an important asset to any agile scrum team. They determine the certainty in an uncertain world of agile software development. They take the naive, the vague and turn it into a valuable product that increases ROI, increases product utility, as they meet time to market goals.

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.