Author: Judith Mary Khan

A Roadmap to Agile

Written by Judith Mary Khan on March 21, 2018. Posted in Articles.

Transitioning to Agile is well worth the effort and benefits, but the way is not always easy and can be filled with issues and frustrations, as well as wrong turns.

To try and be successful in your transition, use a roadmap for the effort, and plan to spend some time and effort on the journey itself. Steps to start can look like this:

Pick the right person to lead the transition effort. This person will have energy and enthusiasm, and insight into Agile.

Pick a small project, one without a lot of complexities surrounding its next release target, and one with team members ready to learn.

Use a collaboration tool that may already exists in your org or purchase a limited number of licenses on something new, or select a different method to collaborate such as a wall board.

Get together with team members and set some goals, gain a common understanding of what comes next, and what comes later.

Expect the change to take some time and energy.

The lead of the transition effort can secure the collaboration tool and users’ access or create the wall board, schedule the meetings, and answer questions as they surface.

Plan for the first phase:

Pick a practice or a handful of practices to start with, such as changing requirements to stories, then start using the tool or wall.

At a round table, get everyone’s buy-in and ownership-of a workflow, keeping it simple for this first phase.

Schedule and set expectations of a daily standup.

Estimate your stories or translate estimates from the Project Plan.

Start sprinting, with a Sprint Planning session.

Have a retrospective at the end of every sprint for a while, even if just to share, question, and vent.

By roles, have each team member do some part in transition prep, a possible list could look like the one below:

Agile Lead: secure the tool or wall for collaborating, schedule standups and a Sprint Planning session for 2 or 3 weeks forward. Use Agile terminology, to start making it common language.

Product Owner (BA): start to translate the highest priority requirements into stories and organize them into epics, facilitate with team member inputs.

Create the backlog and prepare stories for Sprint Planning. Readiness means that the stories will have the details of the requirement, be useable by developers and QA, and be estimated. Work with the business to start ordering the backlog by priority.

Developer: Contribute to grooming the former requirements, now stories, with the PO/BA and give your best-guess estimates.

QA: Contribute to grooming the former requirements, now stories, with the PO/BA and start deriving your Test Plan and Test Cases. Follow the Backlog order of priorities.

Lead (again) be ready for Sprint Planning, and in the beginning, invite everyone to contribute and participate.

Leadership needs to be involved too, especially at the start and through the first phase. Whoever has the power and authority to set a directive needs to step forward and communicate clearly that this is desired by the organization and that the participants need to participate. This is critical in overcoming resistance, even among team members who seem to be eager and willing initially.

The next step is to set the objectives for phases 2 and 3, and onward. This will accomplish two important aspects of success:

setting shorter term goals that are easier to reach
measuring success by outcomes

As well, creating and displaying a phased roadmap can instill the idea that Agile is ongoing in its adoption, continuous as the team grows into it, and a practice that can optimize over time.

And, information can be shared and leadership can take note that there will be slow changes not only in delivery, but how people are working. At its best, the list below is how teams and individuals transform:

Authoritative hierarchy -> self-organized
Silo’d work -> interactive
Predictable and rigid delivery of work -> nimble, and changing or changeable
Documentation heavy -> documentation light
Formal communication -> transparent and informal communication

These changes are significant for teams who experience them. Many people have spent a career honing and executing specific skills and may need time to change their way of working. Others, may have recently finished school where Agile-like practices were the norm. Changes in the workspace atmosphere and social interactions should not be underestimated. These personal, and interpersonal changes require support and attention from leadership. Stress and resistance can best be eased through inclusion, especially in decisions, and fostering ownership of results by the team members themselves.

After at least 3 sprints, a team will be ready to look back and start planning for Phase 2. And in an Agile approach, they can set sights on what Phase 3 will look like. Post and socialize your roadmap to see what comes next, and be sure to come together often as a team at round tables!

What Not to do When Going Agile

Written by Judith Mary Khan on December 22, 2015. Posted in Articles.

Going Agile can be an exciting challenge, and at times, daunting and confusing. The list below describes all too common mistakes that lead to frustration and stress for the team.

Whatever your position, use this information to help keep your transition to Agile on track.

Don’t think Agile means a ‘free for all.’ As managers, put essential, and flexible work processes in place. Let the team come together to define those processes. Always bring the team to consensus, then publish, communicate, and introduce workflows, especially to new team members. Create enough of a framework for the team to rely on expectations and have a cadence to their work and delivery schedule.
Use a tool for stories and defects (like JIRA), and plan how it will be used. This should be done collectively by management, the BAs, Developers, QA, and any other stakeholders who will use the tool to perform their work. The team needs to understand, capture and express what the tool will do for them. Whichever tool you use, it should provide progress in real time and be automated once the status reporting requirements have been gathered. Make sure the dashboard view is available to the individuals who want to have access.
Publish the workflow and make it readable. It always helps when everyone has the same notion of the next step.
Have an onboarding plan for new team members, even if they are internal to the organization but new to the project. Share the shared information.
Define what ‘acceptance point’ or ‘acceptance criteria’ means. Make sure they are clearly stated in the User Story. It is critical for the Product Owner to contribute here as she/he will be the final word for story acceptance.
Have a formal time and system in place with the product owner for story prioritization. This is easy to overlook or to misunderstand as something given.
Managers should provide access to and funding for training if it is wanted. Include contractors too, as they will need to be on the same page as the rest of the scrum team.
Leadership should be clear that rapport, availability, and participation is expected of all stakeholders and team members, sometimes at a moment’s notice.
Product Owners need special attention understanding their role. They will spend more time on a weekly basis dedicated to the activities involved in Agile vs. Waterfall methods. Beyond the initial prioritization and periodic status updates, the product owner will be a critical player in the new method. They will be involved in continuous prioritization, story refining, and defining the acceptance criteria. Don’t underestimate that demos and release notes will be more frequent too.
Project Managers are a great asset to the scrum team, although not technically part of it. If an organization uses PMs, tasks of reporting, tracking, presenting can be funneled to the PM by the Scrum team and the tool. The PM can be the unofficial team member that keeps all the deliverables accountable and reflect this information in the way that PMs do.
Schedule meetings in advance. Elaborations, pre-grooming, grooming, scrum planning, retrospectives, and don’t forget demos! Keep in mind that it is a continuous effort of requirements definition, development, testing, planning, and delivery that occur simultaneously.
Set limits when change can occur, for example, if a new requirement is requested the day before scrum planning, set clear expectations that the Story may not be ready for commitment the next day. Keep the tendency to override common sense in check. If it is possible to include a Story on short notice, Agile will accommodate it. If not, though, it may be best to plan for the next iteration and present a properly written Story.
Don’t assume that everyone in the team knows Agile and how to contribute. Team members can have different amounts of experience in Agile, and even experience in different organizations. Have a protocol for story development and workflow. Clearly state that while the expectation for each role is described (for example QA will own the QA tasks and activities), also press that flexibility and a willingness to work cross functionally is expected.
Don’t use Story Points to equal any of the following:
1. Business value
2. Time measured in hours or days
3. Productivity measured by points
  Do use the following to estimate:
4. The level of complexity for the deliverable
5. Ability of the team members
6. Capability of the team as a whole
7. Availability of resources
Managers shouldn’t overload the team, iteration after iteration. Agile moves quickly and the goal is to deliver successfully at the end of the iteration. Overloading will just burn out your team. Try to balance time in a healthy way.
Don’t assume that it is easy for people to change the way they do their work. It can be a stressful and confusing experience to move from Waterfall to Agile, especially for individuals who have been comfortably ensconced in their waterfall position for a long time. Anxiety may surface. It needs to be recognized and eased with stability and balance.
Don’t think it will happen overnight. Change takes time. Like the expression, you can’t make a baby in one month with nine mothers, in all cases, it will take nine months.
Plan for defects and bumps in the road. Be ready for workarounds when the unexpected happens.
Don’t miss the chance to cross train. Everybody needs a backup or two, and as possible and as able, team members should be able to back each other up.
Don’t recreate Waterfall with the face of Agile stand-ups and JIRA. The benefit of User Stories vs. cumbersome requirements documents is to streamline delivery of requirements. Use the Story framework to capture requirements at the appropriate level of granularity, and to articulate the acceptance criteria. Developers need the chance to enhance the Story with solution ideas. The Quality Team needs to use their method of choice to capture and track testing. The Product Owner needs to keep reviewing and contributing to Stories as they move towards scrum planning and commitment.
Don’t be afraid. Change can be embraced, even when it is the way you do your work. Remember that Agile will streamline your delivery, and lift the weight of documentation. Team members should approach estimation with their best judgment. Over time, the meaning of your team’s story points will be well understood and estimating will be refined. Managers need to give the team time to adjust and don’t hold them to velocity demands, at least in the beginning.
Don’t ‘not-talk’ to each other. The scrum team needs to be open and willing to talk. The open space for scrum team office designs has this intention. Conversations should be easy, and information shared willingly. The best teams understand that each member is needed, and when the members are strong, the team is strong.
And perhaps most importantly, don’t be mistrustful of each other. In an Agile team, the success will be directly mapped to the level of trust the leadership and team members share. Each person needs to be valued for what they bring to the delivery objectives, and each person needs to be entrusted with their role.

Working in Agile can and should be a challenging but equally rewarding experience. As professionals, we choose to be part of software development for the unique qualities of creating, building, and delivering technology. Agile done right, can be the optimized experience of true teamwork. Work through the transition with patience and tackle each roadblock that surfaces one by one, just like the approach to developing and delivering great software!

How to Optimize Your Agile Team

Written by Judith Mary Khan on November 23, 2015. Posted in Articles.

Leaders, be they program managers, executives, or directors, need to support this team. A simple guiding principle for leadership is to understand that the people who work in an Agile environment want to perform. From that, good leaders need to understand each team member’s unique skill set, talents, and career goals.

And to make it a human experience, understand what the team member ‘likes.’ I put this in quotes because I believe it was one of the best interview questions I ever was asked. The top executive asked, ‘what do you like…?’ It was an opportunity to respond quickly with a professional answer, but to also connect in a human way. I answered promptly and got the job offer. On the first day, I felt the upper management had both insight into my skills, and an understanding of what made me tick.

Good leaders are able to exercise this insight and then work from a place where they have enough information to make sure the right people are in the right roles. And, to complete setting up the environment for people to express their talents and interests, the leadership needs to set the bar for respect and professionalism. This will vary from organization to organization, but an insightful leader will know how to meet the unique cultural and individual needs of the team. This is especially accessible in an Agile team, the work moves so quickly, and the team works so closely together, good leadership with clear vision expresses itself readily.

Optimizing the Agile BA and all of the Agile Team

In order for leads to gain a clear understanding of the BA team’s capabilities, it is crucial that the leaders know each of their BAs. Take a pH test and ask yourself questions about those whom you direct:

Do you know your BA’s backgrounds? Strengths? Weaknesses? Aspirations?
How long have they been a BA
Why are they a BA?
What are their career goals?
Are they CBAP certified? If not, do they want to be?
Are they happy with their role?
Do they feel productive at the end of the day?
Do they come in with new ideas in the morning?
Is there something they want to do on the team, but haven’t had the chance to?
Do they have an idea they want to share? A concern?
Do they have kids? If so, how many?
Do they have pets? If so, how many?
Where would they like to go for lunch if you asked?
What do they like to do besides work?
What makes them tick?

Other questions to ask yourself or ask your team members:

Have you provided a framework for your team to perform? Not a rigid, over-worked process but the essential structures to support an efficient workflow.
Have you published this info? Examples are IT management 101’s like: ‘Do you have backups? And do people have a way of knowing who are backups?’ or ‘Do you capture and publish knowledge with an efficient tool that is available to the team?’
Very importantly, for the sake of continuity amid changes: ‘Do you have an exit plan for team members leaving and onboarding?’
Do you treat contractors with equal interest and respect as FTE’s? Do they feel like valued members of the team?
Do you listen to your team?
Do you listen ‘between the lines’?
Do you ask team members what they think? Do you listen to their answers and empower them to usher their ideas?
Are you sensitive to the cultures and multi-cultural dynamics among team members? Do you know about the cultures your team members may have come from?
Perhaps most importantly, are you available to your team members? Do they feel they can talk to you?

With this kind of increased knowledge of the team’s dynamics, managers can be empowered to make decisions that provide the infrastructure to optimize performance. This is a win-win situation for the individuals involved and the eventual output of the project.

Related Article: Want a Successful Agile Team? Include a BA!

Another possible method to gain insight into how your Agile and BA team is performing, and to understand where BA energy is going, is to use a BABOK-centered tool that I once had the chance to put to use. In a large organization where I worked, the BA team was disheartened by their workload, but even more so, the type of work tasks and activities that occupied most of their days. One BA shared with me that he barely felt that he worked as a BA! The management and directors felt the team was weak in its performance. They were oblivious to the root causes of mediocre delivery. Their idea was simplistic: to put more pressure on the already unhappy BAs. I needed to make a persuasive case to management to reorganize and re-delegate how work got done.

In order to capture exactly how the BA team was under-utilized, I constructed a calculator that was based on the Key Processes Areas of the BABOK. The instructions were as follows:

Step 1: At the end of each week, BA’s should enter the percentage of time that she/he had spent in each of the BABOK KPA’s listed. For work that did not fall into one of the KPA’s, it should be entered as a ‘non-BA activity’. Ten percent would automatically be allocated to administrative time.

Below is a sample:

Note: Be sure that BA’s have autonomy in this data capture, and that it does not become ‘hourly’ time tracking.

Step 2: Capture the percentages for a month, then summarize in one graphical representation.

Step 3: Capture this information for 3 months (1 quarter), summarize, and present in a graphic presentation.

Step 4: Collect what activities constituted ‘Non-BA Activities’ and describe it in the presentation to management.

Step 5: Present this information to management and executives involved in decision making.

Step 6: For management, use this information to plan for greater use of BA talent and skills, use this information to support BA team members in strengthening their weaknesses and planning education for the teams. For leadership, use this to diagnose a project’s weaknesses or challenges to delivery. Incorporate this into strategic thinking and decisions.

This is one tool, one way to gain insight into the true dynamics and functioning of a team. The set of questions can be very useful, especially for the out-of-touch leader. An Action plan could be derived using these, and including more, customized to your unique team. By using information in a meaningful way, leaders can be empowered to make truly innovative decisions. Over time, this will build the framework for an Agile team to be optimized, and for a success story all around!

There must be 50 Ways to Write a Great User Story

Written by Judith Mary Khan on October 12, 2015. Posted in Articles. 1 Comment on There must be 50 Ways to Write a Great User Story

The user story is the center-point for the Agile business analyst to perform work. From the story, everything else can be facilitated, requirements definition and communication, development and QA tasks that will bring it to completion, tracking and reporting for the team, management, and even the customer, and even knowledge transfer for future team mates. All of this is possible with the well-written story.

During the time that I have worked as an Agile BA, I have seen stories used in a broad spectrum of manners, those that are completely cryptic in what their purpose is, those that read more like random defects recorded by IT and/or non-IT people, those that are largely dependent on tribal knowledge, and those that are concise, clear, and deliver all the important pieces to be truly useful to all the team, as well as non-scrum team stakeholders.

I recently decided that while the story can be used in numerous ways, a good story will have certain attributes. Check the list that follows and see if there are more ways to write a good story. In an Agile team, the flexibility will be built into it by doing what makes the most sense to your unique project and your unique team. The rigueur of waterfall methodologies will not limit the Agile BA to a strict set of requirements to fulfill in getting acceptance of the requirements documentation. It will also expand the BA’s capability to communicate across teams and simultaneously contribute to the library of project documentation.

Keep in mind, as the owner of the user story, seek to communicate efficiently, and with clarity. Do not bury the meanings, purposes, objectives in verbiage that is not readily accessible to the spectrum of stakeholders that will be the consumers of the story. In depth technical details, and even details of business process information can be included in the story, but as a subtask requirement, or an image or attachment to the story. Keep your headline reader ready! This applies to Developers and other technical team members to the business customer and executives. Make your handprint on the story by offering clarity, versus one that furthers confusion.

How you write a great story is up to your own project and style, but make sure it has these qualities.

Here are a few ideas:

A great headline reads like a story, not a puzzling technical paraphrase.
A description that cuts to the chase and is readable by all scrum team members.
Use story notes. If this is available, capture and describe aspects and details beyond the description.
Capture the tasks involved for specifying the requirements, the work of the Developers, and the criteria for QA activities. My current team makes this quick to grasp with prefixes to indicate which team member is responsible, such as ‘DEV’, ‘QA’, etc.
Clear acceptance points or criteria are written so that any business analyst can walk through the deliverable and give it a yes or no to pass for acceptance, or to pick up the workflow. It should be cross-team member ready.
A workflow that makes common sense and uses verbiage that can be readily understood. This workflow should be visible to all users, and permissions granted only for those who are in the appropriate role to select that workflow step.
The right screen shots should be attached, but only if needed.
Attachments can serve as directly related to fulfillment of the story, and become a powerful reference tool in future use when investigating the history of a feature or whatever was important to the story. Meaningful and supporting attachments can also guide the knowledge transfer when new team members join.
Comments should be direct, and to the point. This is all too often overused, for comments that do not need to be captured and reread. Valuable comments are readable, complete, and understandable. Any ‘next steps’ or action items that come out of a comment need to be clearly stated.
Use the story points to track, communicate, and reflect the best estimating available from the team. A lot of skill goes into good estimating and the various team members have a lot to offer. Make sure that all voices are heard, especially from QA and UAT.
Use your story to facilitate prioritization. Keep the ranking within the story itself. This can then be ready to use when reviewed, reported, analyzed for metrics. The PM, and the dashboards that can be created will thank you.
More… employ the elements that will make it valuable to your team and efforts. Agile allows options, and as the BA, you can facilitate it.
More as you can think of them!

All of these pieces work interdependently to define, communicate, and deliver requirements. The Agile BA is the one who ushers the story, facilitates the collection of story components, and gives it a consistent tone, style, and voice.