Author: Andrea Reese Hurst
At the request of an engineer who I wrote requirements for, I jotted down some tips for good requirements gathering in a software setting. Here they are, a bit tidied up:
Identify the end users, the project owners, and other stakeholders who influence the success or failure of this effort. Schedule time as soon as you can to talk with each of them – especially end users – about their role, their pain points, and their vision for the project. This focuses your efforts and helps get buy-in from all parties early. It dramatically reduces last-minute objections that come out of the blue to torpedo your schedule.
Have the end user walk you through their current process. Specifically, document:

1. where they get the information they need (such as systems, publications, and people)

2. what they do with that information in the course of their work (including what systems and tools they use)

3. what their outputs are, and

4. where or whom they send the outputs to.

Laying this out clearly may help you see a previously invisible solution – maybe they just need access to some useful reports instead of a whole new interface, or maybe there’s no real problem with the current method after all, or maybe the problem is much larger and requires interdepartmental cooperation to address. Regardless, it’s good information.
Document pain points without jumping to solutions. As your stakeholders review their process and pain points, they might propose specific solutions. Acknowledge and document all suggestions, but don’t commit to any one approach yet. As you build a more complete picture of the problem, your team can develop the best solution to address pain points systemically rather than patching together incompatible or costly feature requests.
Gather requirements iteratively. Start by roughing out objectives and requirements, and then get feedback and refine them until they’re ready for development. If you ask stakeholders up-front for permission to follow up, most will be happy to help. People generally love being asked their opinion. For complex projects, schedule a recurring meeting to run through follow-up questions regularly as you refine the project.
Don’t commit to schedules or features with the customer until the project manager and solution manager have nailed down the scope and prioritized the features. Actively manage customer expectations of what they’ll get, by following up on discussions of features by reminding them these are potential solutions that still need to be prioritized and discussed with developers for feasibility.
Talk over the prospective features with development leads to get a feel for feasibility and scope before you go very far down the road of writing up the requirements. They’re the ones who will be doing it, and they know better than anyone what their teams can do by when. Some people call this “T-shirt sizing” where features or user stories come in sizes XS, S, M, L, or XL.
Get the decision-makers’ priorities. Ask them what features are absolutely critical for operations to continue, and then go down the line to the nice-to-haves. One helpful set of categories for this is MoSCoW (Must, Should, Could, and Won’t). Make sure you know why they categorized each feature the way they did.
Author: Andrea Reese Hurst

Posted in PMO

Author: Andrea Reese Hurst
Coming from a waterfall development environment, I was used to polishing a requirements document to the nth degree before handing it off to development, but in an Agile environment, this put me behind schedule, and didn’t even make good user stories. Here are a few things I learned while working in Agile for a few years:

  • Give the developer all the information they need to get a good start on the user story. The developer wants to sit down, plug away at a user story, and knock it out. You don’t have to be exhaustive, but give them enough to begin without contacting you first.
  • Briefly summarize why you’re entering the ticket, whenever it’s not self-evident. When the dev knows your purpose, he or she may have a better solution. This is especially true of user stories that aren’t well-defined.
  • Give the specifics up front if you have them. Don’t make the dev come back to you for stuff if you don’t have to.
      • – Specify exact column names, field names, names of roles, and any other information the dev will need to finish it.
    • – When the ticket involves complex permissions, or a variety of data sources, attach a spreadsheet specifying precisely what those are. It may seem like excessive detail this early, but it’s not.
  • Include a picture of new features. Attach a mockup of any new features if you care at all how they look (which is 98% of the time if it’s for a business user).
  • Break out compound requirements. If the requirement has a bunch of subrequirements, create an epic with links to subsidiary user stories rather than one huge story with bullet points. This
    • – lets the dev take ownership of one subtask, mark it done, and move on, which is more Agile and – let’s face it – more rewarding than hacking away at one monstrous requirement for a month
    • – lets multiple devs chip away at it
    • – allows you to prioritize, comment on, add, or close out individual stories without affecting the other pieces
    • – lets you and the project manager track issue progress more granularly.
    • Make them aware of gaps. If you’re not sure of something but the requirements need to go out, add a comment specifying what information is missing (e.g., “Andrea needs to find out from Jeff whether we already have access to Table X,” or “Customer needs to finalize wording with Sales Department”) so the developer knows to come to you for an answer when he or she gets to that part.
    • Don’t repeat yourself. Give them less to sift through. For example, if the mockup covers the layout, don’t describe the layout – just refer to the attached mockup by its file name.
    • Ask for feedback on your first several requirements. When you’ve drafted your first batch of requirements, take them to the development lead and ask if these work, and whether you could make them more useful. Let them know you’re always open to feedback.
  • Follow the item in the work tracking system. This helps you stay in the loop so you can report on the status of the ticket to your client, make sure development understood your requirement, and respond to comments by the devs or QA engineers.

Author: Andrea Reese Hurst

Posted in PMO

Author: Karen Stackhouse
I’m often asked about the difference between a Scrum Master, a Project Manager and Product Owner.  They all are very distinct roles and are interconnected and dependent on one other.
So, what’s the difference?  In Agile development there is typically a Product Owner and a Scrum Master.  Depending on the organization, a Project Manager may also be part of the overall team.
The Product Owner is responsible for the overall product development and its lifecycle.  They set the vision and the metrics for the product (through market analysis, control groups, etc.).  They also maintain and prioritize the Product Backlog (consisting of user stories) of features.
The Scrum Master is responsible for managing the work of the team developing the features.  They work with the delivery team to deliver features, monitor the team progress, work to remove impediments and protect the team from outside influences; they are responsible for the overall health (both progress and satisfaction) of the team.  They work closely with the team and the Product Owner to ensure the Development Backlog is groomed and is maintained to maintain project velocity and progress.
In general, the Product Owner maintains the vision of the product and the Scrum Master works to make sure the vision is met according to the Product Owner’s specifications.  In some organizations, a Project Manager is injected into the project team.  Their main responsibility is to oversee budget and timeline and work in cadence with the project team to make sure the project is delivered accordingly.  If the Scrum Master is tasked with monitoring budget and timeline, they take on the responsibility of the Project Manager; however their main task is to oversee the Development Backlog and the health of the team and report progress upward to Management.
A Project Manager maintains the budget and timeline of the project and reports status to management.  They also coordinate with other organizational project efforts to make sure that the organization as a whole is healthy from a strategic vision.
the flow between product owner, project manager, and scrum master
In general, the Product Owner maintains the vision of the product, the Scrum Master works to make sure the vision is met according to the Product Owner’s specifications, and the Project Manager is tasked with managing the budget and timeline and ensuring the company’s strategic vision is met.
Some organizations choose a hybrid of the Scrum Master and Project Manager roles.  If that is the case, the Scrum Master takes on the added responsibility of the budget and overall timeline.  This hybrid is one that is become more common as organizations streamline their staff and task them with greater overall knowledge of the organization’s vision and processes.  This doesn’t change the Scrum Master’s responsibility to maintain fluidity within the product and development environment and protect the team from outside influences.
As a consultant, I typically fill a hybrid role, since my clients require I manage the budget and the team on a daily basis.  I use the general tenants of Scrum (Daily Stand Up, Sprint Planning, Retrospecitves).  I also have the team participate in consistent backlog grooming where we review the stories, estimate them and add any information required for development and acceptance.  I have the added responsibility of overseeing the budget and overall timeline and reporting progress to management.  I may not be the Scrum Master in the traditional sense, but I’ve found with support from management and the important input and responsibility of the Product Owner, we can create success.
Author: Karen Stackhouse

Posted in PMO

Author: Mike Chatwin
I have heard horror stories from colleagues of daily scrum meetings that run over an hour…
STOP IT IMMEDIATELY! A daily meeting running this long becomes a roadblock to several of the basic principles of the Agile Manifesto (

    – Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    – Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    – Simplicity–the art of maximizing the amount of work not done–is essential.

How can these principles be met, if the team is locked up for an hour EVERY DAY? It is the responsibility of the Scrum Master to assist the team in efficient delivery of product.  Start with the daily Scrum!
Cardinal Rules of an Effective Daily Scrum:
– The Scrum should start on time
– The Scrum should take NO MORE than 15 minutes.
– The Scrum is for each team member to answer “The Three Questions”

What did you accomplish yesterday

What will you accomplish today?

What issues are keeping you from delivering on your commitments?

– The Scrum is NOT to discuss technical details, administrative stuff or solutions. (Those are more efficiently handled off-line).
Remember, an effective Scrum Meeting is a SHORT meeting!  Minute details and follow-ups can be done without tying up the entire team!
Also, it is a good idea to conduct this meeting with everyone standing.  This encourages the team members to keep it brief!

Why are the “Three Questions” so important to a Scrum Meeting?

A Scrum Meeting is the opportunity for each team member to answer the “Three Questions” of Scrum:

What did you accomplish yesterday

What will you accomplish today?

What issues are keeping you from delivering on your commitments?

The three questions and the Scrum meeting are only partially about communicating status.  A good Scrum Master will already have a good idea of the status of his backlog.

The ceremony of the three questions is about making a commitment.

The team member is reporting what was accomplished the day before… then COMMITTING to the day’s activities. And declaring risks to meeting that commitment.  This public commitment establishes ownership over that particular user story.
Again, the Scrum Master should analyze progress on stories.  If a team member is spending an unexpected amount of time on a story, determine why.
It is actually MOST efficient to make this a ceremony.  ASK each team member the questions, and record their answers.  This cuts down on rambling.  Lengthy discussions should be deferred until after the scrum meeting.
When the meeting is over, the Scrum Master is responsible for:
– Removing barriers to the completion of stories.
– Analyzing progress.   If a team member has been working on the same issue for several days, investigate.

Was the size of the story underestimated?

Is there an impediment that the team member is trying to resolve alone?

– Follow up on any technical discussions (they were deferred until AFTER the Scrum Meeting.  Make sure they aren’t forgotten completely).
Scrum Masters, be mindful of the time spent in your Scrum meetings.  If they are consistently longer than 15 minutes, analyze and improve (a basic tenant of Agile!)   Don’t ACCEPT a long Scrum meeting!   Keep it under 15 minutes!
Author: Mike Chatwin

Posted in PMO

It is common to read articles and posts which say that the issues that organizations face when developing software are bigger than ever before. However, in many ways we face many of the same issues now as those that were common in 1975 when Fred Brooks wrote his famous essay on issues facing software development companies, “The Mythical Man Month”.
The issues discussed in “The Mythical Man Month” have not so much changed as the options for fixing those issues have grown and morphed into better solutions. Every business is different and they all have their own sets of challenges. We can categorize issues that businesses face by the size of the organization. Large businesses have more employees, harder to handle communications, and more strenuous processes that must be followed. With that in mind let’s explore five issues, and their solutions, that large organizations face as they try to find success with IT.

Big Design Up Front

Large organizations have a number of challenges which often seem as though they can be solved by the concept of big design up front. Executives want to know when they will be able to see a return on their investment. Marketing and sales teams want clear deadlines so that they can begin to share information with customers about new features. Engineering management want to be able to plan what will be developed with project management groups. Operations teams need to be able to plan and purchase needed hardware to support these new products.
It is exactly these pressures which cause companies to attempt to design every facet of their software as early in the process as possible. Big design up front is the process of trying to architect and plan everything in a project before ever writing a line of code. Often big design up front will lead to long schedules filled with development tasks which take a product down the wrong path and do not leave room for an organization to learn from their customers as development proceeds. Big design up front may alleviate the initial pressures of development by creating schedules, but it will also often lead to product failure.
Obviously companies can not just ignore these initial project pressures. The solution to these pressures is to adopt a goal to deploy to real users early in the development process and often after an initial release. At Hewlett Packard, on a consumer facing project, we made a goal to release to a small set of customers in the first week, and weekly after that. By doing so, everyone in the organization could plan and prepare for constant customer interaction. Additionally, the company was able to receive customer feedback early and pivot quickly as it saw areas of innovation. This sort of goal, as opposed to big design up front, leads to quick and consistent success.

Not Quite Agile

Many organizations I work with call themselves agile. However when pressed to discuss what agile methods they follow companies will stammer out an explanation that we in the Agile community call “Scrum But”. “We are scrum but we don’t have stand ups,” “… but we don’t write user stories,” “… but we don’t demo to stakeholders”. This list can get quite long and before long the organization is not so agile at all.
Large organizations need to understand the agile mindset now more than ever before. Agile states that an organization should value:
● individuals and interactions over process and tools
● working software over comprehensive documentation
● customer collaboration over contract negotiation
● responding to change over following a plan
Large businesses know that agile is important but they fall into the pit of “Scrum But” when they forget the real tenets of agile. Companies need to remember that agile is not scrum. But the rules of scrum, as well as extreme programming, lean, kanban, and many other so called “Agile Methodologies,” if adhered to, will help an organization to follow the four truly agile principles.

Too Many Meetings Not Enough Action

Large organizations often complain of communications issues. With dozens of levels of employee and management between the software producers and the executive teams it is easy to see how communications can become problematic. Most people within organizations have an honest desire to communicate status, changes, and issues to both their supervisors and their subordinates. However this honest desire to communicate generally leads to a crippling number of meetings. These meetings often hamper the amount of work a team can complete.
Organizations in recent years have turned to agile practices in an attempt to alleviate these meeting needs while still keeping communication channels open. This is a good tactic as long as it is kept in check. All too often companies allow agile to become a reason for more meetings. Daily stand ups turn into multiple hour status sessions. Sprint planning can turn into multiple day marathons. When agile methods are not kept in check they are not agile at all.
When agile is used correctly it can reduce the meetings and increase communication. An organization must work to have an effective backlog and to make sure all of the stakeholders in an organization have access to the list. A prioritized backlog can tell stakeholders, even at the executive levels, more in a few minutes about development efforts than weeks worth of meetings. Additionally companies must be diligent in keeping their agile meetings agile. Stand ups must be kept to 15 minutes of less. Sprint planning should be under an hour. Other meetings should be kept to a minimum or eliminated. By keeping a prioritized backlog and keeping agile meetings agile, organizations will see engineers complete more software development and meet less.

A Lack of DevOps and Automation

Whenever I start a new engagement I always ask how the company deploys its software. Often the company will complain of the long and arduous process of moving their code from environment to environment. The process usually involves a myriad of manual steps and is quite error prone. The longer and more error prone the process is, the longer the organization will wait between releases. This is not good for the development process nor for an organizations bottom line.
This is why DevOps and automation is so important. DevOps is the intersection between development and operations teams. Before the DevOps movement engineers working on products would complete features and then “toss” the code over to operations for deployment. Operations would then try to replicate a development like environment on production hardware, deploy the code, and debug any production issues. This method of deployment is ineffective and expensive.
By implementing a DevOps strategy which includes the automation of both the server configuration as well as software deployment organizations can speed up the deployment of their software. Product engineers must help in the process of automating these steps. Companies can no longer tolerate an internal atmosphere where product engineers create software in a vacuum and then toss the results over the fence to operations. As product engineers plan their development activities they must add tasks to automate and test deployment strategies.

Rebuild Or Hand On Too Hard

Large organizations can on occasion fall prey to their own success. Unlike bootstrapped or venture backed start ups, large organizations often have the capital needed to invest in very large software projects. These projects do occasionally go awry. When that happens companies will either decide to rebuild or hang on and keep trudging forward with their software development. Depending on the circumstances these scenarios can be detrimental to the company and the development teams.
When a large software project starts to have huge problems is may seem like the best plan is to rebuild the project from scratch. This stems from the nearly universal good feelings that come at the beginning of a project. Tasks complete quickly and progress often is fast in the early project stages. But if there is a problem in an initial project it will be exacerbated in a rebuild project.
Similarly, companies in distress will sometimes try to hang on to a failing project. They do not want to lose the perceived value, and cash, they have already put into a project so they trudge forward hoping things will get better. Again when a project has issues this desire to trudge forward, throwing good money after bad, will exacerbate the issues.
The answer to these issues is not to rebuild from scratch or trudge forward blindly but to find the underlying issue in the project and eliminate it. Often the project is having issues because of ill defined requirements. At other times simple processes are being made overly complex. It is also not uncommon for a project to no longer be of value to the organization. It is better to understand the underlying needs and address them than to blindly rebuild or hang on.

Where Do We Go From Here?

Large organizations are obviously not immune to issues when it comes to IT. Unlike smaller businesses, large organizations have a huge number of employees, levels of management, high budgets and budget constraints, and rules and regulations to follow. When we look over these issues that have been presented, it can be seen that they creep in because of the unique environment that are within these large organizations. However, by following good principles such as true agile methodologies, keeping communications in check, automating, and making solid businesses decisions when issues arise, we can overcome problems within our large organization IT departments.