Author: Robert Galen

I See What You Mean… Leveraging Transparency!

Written by Robert Galen on February 23, 2010. Posted in Articles. 1 Comment on I See What You Mean… Leveraging Transparency!

One of the core tenets of the agile methods is transparency. I’ve been doing agile for nearly 10 years and this is one of the tenets that I find myself understanding and appreciating more and more as I gain experience. It’s the tenet that keeps on giving.

Let’s generally define it first. What is transparency?

I think it comes down to exposing the inner workings of a software project for all to see. To have high comfort and honesty in sharing project “state” with team members, stakeholders, and company leadership. Included is the ability to engage in honest, open dialogue surrounding any issues leading towards requisite project adjustments.

How Do You Foster Transparency?

The first part of it is simply sharing “state”. For example, I view early reviews of requirements documentation as being a transparent moment-particularly if they’re incomplete. In Scrum, each iteration ends with a Sprint Review where the team demonstrates the code and artifacts they’ve created during the sprint (iteration). There’s no simulation here. Instead the emphasis is always on working code and relevant models completed in the sprint.

So, stakeholders can see and react to exactly what we’ve done so far.

Another Scrum practice is the daily standup meeting or daily scrum. Here the team gets together and shares the progress and challenges they’re facing in the current sprint. If they’re behind, it’s evident and corrective action discussion occurs in real-time. If they’re ahead, then discussion surrounds pulling more work into the sprint. Either way, you understand the ebb and flow of the work on a daily basis. Scrum teams welcome visitors to the daily scrum as a means of transparent status gathering.

A final Scrum practice that fosters transparency is the notion of a Burndown Chart. You can see an example below. In this case we’re burning down cumulative work that the team planned over the course of a sprint or iteration. The green line is the perfect trending line. Each day, the team gets credit for completed task work and “burns down” the chart hours appropriately. You see in the example that the blue line gives an entirely different view of the team’s progress than does the red. It opens the door for questions from the team and stakeholders – leading towards comfort or adjustments.

What Does Transparency Do?

It removes wishful thinking on the part of the team and stakeholders. Instead of thinking that the project is about 40% complete, a transparent view is that 32 of our 96 features are absolutely complete, with 12 being works in progress. That implies that we are exactly 33% complete. And at this rate, it will take us twice the current progress interval to get the work completed if the features are roughly the same in size and complexity.

It keeps us grounded in the now – not worrying too much about the future. Instead, how are we trending towards our next deliverable? And, if not so well, how do we take corrective action now to improve our potential for delivery?

It creates conversations surrounding reality and movement towards your goals. I literally love it when a stakeholder stops me in the hall and ask about our current burndown chart for a specific Scrum team…

“Bob, I’ve noticed that It’s day 4 of a 10 day sprint and the burndown chart seems to be flat. That implies that we’re not making our expected progress. Yes, it does, I say. Well what can we do about it? I offer a couple of thoughts. First, we don’t know if we have an issue yet. The team may simply be working on things that haven’t been integrated yet, and we’re “on track”. So we ought to engage the team and ask them how things stand – perhaps in tomorrows stand-up?”

If we are tracking worse than expected, then I’ll engage the stakeholder right then with trade-off options. I’ll direct them away from quality trade-offs and focus on scope. I’ll usually ask questions surrounding jettisoning scope while still being able to meet our sprint goals. All the while, trying to make the problem and the solution ours instead of mine.

So What Does this Mean for the BA?

Leverage transparency to your advantage. Open up your work incrementally, early and often, for review and feedback. Don’t get defensive when you hear things that you don’t quite agree with. Take the feedback, internalize it, and take appropriate action within your work’s flow.

Let everyone know how you’re progressing towards project goals. What are your high priority focus points and conversely, the low priority counterpoints. Let everyone know how your work aligns with the schedule. Don’t hide anything and don’t be optimistic or pessimistic. Just relay where you honestly stand and the potential for adjustments.

I encourage everyone to simply try transparency. It’s the gift that keeps on giving!

Don’t forget to leave your comments below

Agile’s “People over Process”… What’s the Point?

Written by Robert Galen on January 12, 2010. Posted in Articles.

There are several bloggers on BA Times who have written about agile methods. They’ve compared them against more traditional methodologies and missed many of the central themes and mindsets within the methods. In particular, one of the often missed points relates to documentation…imagine that! Let me provide some additional context here.

From my perspective, traditional methodologies (Waterfall, Ad-hoc, RUP, etc.) try to capture the essence of a project in the documentation for the project. The thinking goes:

We’ll gather our best people together
We’ll put them in a room and they’ll think deeply
They’ll architect and develop models
They’ll analyze and write requirements
They’ll design the system
They’ll pull together a detailed, end-to-end plan
They’ll plan for quality and risk and process
They’ll hand it off to someone else to execute…

All of the intellectual property – the experience, the skill, the decision-making, the nuance, virtually all of the creativity has been stuffed into the documents. Usually there’s a view that now that all the hard work is done, all we have to do is find a team to simply execute the details. In fact, almost any team could deliver this “well crafted” project…couldn’t they?

Then Voila! Our Work Here is Done!

The agile methods come at this situation from a different direction. Why? Because the above approach usually doesn’t work. I contend it’s why we’re still failing in nearly 60% of our software projects to meet stakeholder expectations across one or more dimensions of our projects. (Chaos report data) We’ve forgotten an important point in the above strategy. It’s not that the documentation is bad. In fact, we often need much of that work done. No, the thing we’ve missed is the people, the knowledge worker, the team. In other words us!

We’ve forgotten that plans don’t execute projects – people do. Architectural models don’t guarantee a sound architecture that scales well under adverse, real-world conditions – people do. We’ve forgotten that exhaustive requirements don’t guarantee that we delight our customers and exceed their expectations – people do. We’ve forgotten that quality doesn’t get tested in. Instead it gets built in – by the people. Let me characterize it in another way; here is the agile people mantra:

It’s ALL about the People collaborating around real working code!
It’s about writing some more code to verify our presumptions in writing about the code…
It’s ALL about the People collaborating around the new, real working code!

You see you can’t solve problems by trying to predict the future solely within documentation. Here’s an agile-esque and potentially different/better approach to attacking a project:

You find a wonderful, highly skilled team.
They do “just enough” documentation to get started
They include the customer in all decision-making; in fact, they’re part of the team
They start building pieces of the systems, gaining feedback
They’re transparent to the customer, management, and stakeholders about their discoveries along the way
They make informed adjustments as a team and with the business where necessary
They triangulate the project through all of the uncertainty and deliver the most meaningful set of features to the client when they need it

In agile, it’s not about the pre-work or the documents. It’s about the people. Included with the people is the customer. They work together, are inspired and motivated together and they deliver together. It’s about self-direction and honest teamwork. It’s about discussions and openness regarding project state, progress, and trade-offs.

I would characterize any project that elevates and engages their teams in a holistic manner as being agile. Likewise, any project that allows their teams to think and respond with common sense to each project’s unique requirements and challenges as being agile. In the same way, projects that allow them to decide what needs to be documented and, heaven forbid, what doesn’t…because it adds no value, as being agile. In other words, any project that truly trusts and engages its people, can be defined as being agile!

If this describes your project environment, then independent of your software development methodology…you are, gulp, Agile!

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]

Agile BAs… Don’t Go in without TOOLS!

Written by Robert Galen on December 15, 2009. Posted in Articles. 1 Comment on Agile BAs… Don’t Go in without TOOLS!

In my last post I discussed the role of BA as it relates to working within agile teams and tried to explain what you can and should do as part of your team. One of the comments I received related to the role of User Interface Designer in agile. I had implied a complementary role in the post and the reader was looking for a bit more information. I thought it was a really good question and it’s led to this follow-up post…

Applying user interface design in agile methods is one of the leading challenges right now within the agile community. Since it’s an early-on activity, as is any design activity, the notion of sprinting till your done-continuously delivering working software iteratively doesn’t seem to engender much in the way of design.

Thus the challenge…

What design practice has done is encourage the agile folks to slightly reconsider their models. For example, within the design space, it is often quite reasonable to do design work within an iteration, that will only be ‘used’ in subsequent iterations-say the next one or two. This sort of look-ahead from a design perspective is required as the team can rarely implement the work within the same iteration where the design was explored and defined.

The trick is to not look-ahead too far. If you do, you fall into the waterfall trap of designing everything in advance, before you’ve actually gotten a few lines of code to work. (Something we agilists describe as BDUF – or Big Design Up Front and a common anti-pattern of agile development).

So this creates a need to oscillate or balance activities within your agile teams between some look-ahead tasks such as architecture, analysis, and design and then transitioning to coding and testing. I think the best agile teams ‘get’ this balancing act early on and understand that they have to work on both sides of the equation.

There are a couple of tools within the agile arsenal that foster look-ahead. I’m going to speak to a few. While they’re often ignored by the more purist-focused agile methodologists and teams, they are indeed a quite viable tool-set for looking before you leap into iterations.

Chartering. In the same spirit as traditional project chartering, agile chartering focuses on developing the why behind the project. Usually it targets the business case for the project including: target customers, vision for the project, ROI information, budget details, high level scope targets, team and capabilities information, and definitions for success – usually including a schedule or date target. The charter should serve to energize the team by sharing the why it matters behind the project or effort.
Research Spike – User Story. At times you really don’t know enough to write a solid user story. Usually the gap is in technical or design experience and what you really need is a little time to “play around” with things to gain a better clue. The output of a research spike isn’t working code. Instead it’s knowledge – usually in the form of architectural design details and a refined set of user stories destined for implementation in a later iteration. As a rule of thumb, I usually see 20% or so of stories in my backlogs that warrant a spike to gain more clarity.
Iteration #0 or Sprint #0. Quite often agile teams simply dive into their work, iterating before they have a clue to where they’re going. For some projects, this seems to work and the team figures out their direction along the way. For many others, this is a disaster. Jim Highsmith coined Iteration 0 as a term in his Agile Project Management book. It’s defined as a first/early set of iterations that are focused more towards getting ready to begin building a product than on the actual construction. A wide variety of work can be encompassed in a Sprint #0 including, architectural definition, requirement analysis and backlog preparation, design work, setting up office space and building the team, training, project chartering, group planning activities, etc. The caution is not to allow your Iteration/Sprint #0 to extend too long.
Blitz Planning. Alistair Cockburn defines Blitz Planning as part of his Crystal agile methodology. Crystal hasn’t achieved much popularity, so you probably haven’t heard much about it. However, there are techniques within Crystal that are quite powerful and this is one of them. In Blitz Planning you engage the entire team and key stakeholders in defining the overall plan of attack for the project. This includes developing the overall feature set, work tasks, dependencies, identifying key milestones, and such. At the end of a day or more of collaborative planning, you end up with a detailed, end-to-end mapping of the work. This includes when and how you’ll be doing analysis and design in order to effectively drive your agile iterations during construction.
Story Mapping. Jeff Patton is one of the champions of this technique and is actively refining it. What often happens in agile product backlogs is that the individual stories often obscure the big picture and overall direction a product is taking. Story mapping strives to connect individual stories into the themes and feature interactions that your real customers will be using. Typically, it’s a low-fidelity technique where story 3×5 cards on a way are elaborated and refined from the customer workflow and user interaction points of view. It often identifies gaps and helps to prioritize what should be implemented in what order.

For those of you who thought that agile did little in setting the stage in advance of the work, I hope this post and the tools open your eyes to a different perspective. While the agile methods do take a lean, iterative view towards software construction, many projects need some initial vision setting. I also think these techniques can be mapped, to good effect, to the more mainstream methodologies. Happy exploring!

Don’t forget to leave your comments below

What do BAs “Do” within Agile Teams?

Written by Robert Galen on November 10, 2009. Posted in Articles.

For the past several posts, I’ve been focusing on user stories within the context of agile teams-how to write them and the role they play in agile development. This month I wanted to switch gears a bit and talk about the role of the BA within agile teams.

The first point I really want to make is not BA role specific but focused towards the general role of the agile team member. You see roles need to become much less clear or constrained within agile teams. Sure, a developer is still a technical role and will be mostly writing code, but that doesn’t mean it’s the only thing they can and should be contributing to the team.

There’s quite a debate in the agile community about generalists vs. specialists as team members. Clearly the more general you are, for example a tester who can write or read code or a BA who can test, the more flexible your contributions are within the agile team.

The pushback within the community is based on folks taking this idea to its (unintended) extreme, for example developers who believe we’re asking them to morph into full-time testers or vice versa. So, in general, pun intended, you should not view yourself narrowly as a business analyst, but more broadly as a team member who has strong requirement analysis skills against an even broader back-drop of capabilities that you often bring to bear within your team.

So, what specifically is the BA role within agility?

It starts out the same as it does in your existing role. You are a customer advocate and liaison. You have tremendous experience in the analysis and capture of critical system requirements. You have broad collaborative and observational skills. Often, you sit down with a wide variety customers, stakeholders, and constituents and gather and define requirements from a wide variety of angles.

But within agility there is so much more you can do along the lines of the following:

Product Backlog Partner. Clearly the BA role focuses on requirement definition & refinement. Using Scrum as our terminology backdrop, it implies working closely with your product owner, customers, and team members to construct and refine the backlog. Remember, in the agile methods all work should be defined on the backlog, so it’s not simply feature-based. You need to be comfortable defining user stories that represent task work as well.
Fostering Team Collaboration. BAs often become a liaison between the product owner (customer) and the team. They foster an inclusive view that brings team members together to better design and build customer-focused solutions. The methods sort of oversell collaboration as a natural occurrence. I have the view that it needs to be encouraged and often championed. BAs can clearly serve as this champion of collaboration amongst team members. I’ve often seen BAs adopt a facilitative role within their teams, facilitating effective meetings, information sharing, and problem solving.
Driving Quality. Working with your product owner and testers, you help to define, refine, and even execute user story-centric acceptance tests. Often, you’ll view the execution of features from a more holistic, end-to-end usability view that is so important to the customer. Verifying that the software is as simple as possible while still meeting the customer’s usability and core expectations.
Maintaining a Value Focus. Taking a page from Lean Thinking, the agile methods are extremely value and cost centric. Often you’ll see Scrum teams that focus not only on priority to determine what is worked on first, but they also try and determine the value (ROI) for a given feature set. BAs can often help facilitate this value-based analysis between team and customer. They can also help guide the team towards Minimal Marketable Feature sets (MMFs) that implement predetermined value, delivering early and often.
Demonstrating Results. As a full-time member of your agile team, your true focus is towards delivering small slices of end-to-end functionality at the end of each sprint. Be willing to serve as a voice of your team in these demonstrations. Truly understand how the delivered software works and how to effectively demonstrate its value. Don’t be afraid to step into the limelight and demonstrate working code as part of each sprint review.

Often I think of the US Army recruitment commercial, “Be All You Can Be”, when I think of roles with agile teams. As an Agile BA, you should grow your skills horizontally and fearlessly contribute wherever you can within the team. Your teams and customers will value you for it!

Don’t forget to leave your comments below

User Stories – Large Misconceptions. Part 2.

Written by Robert Galen on October 13, 2009. Posted in Articles.

In my last post I discussed two misconceptions related to user stories. First was the notion that user stories are static artifacts and the second was that they stand-alone in representing the nuance of requirements. Both of these views are false. In this month’s post, I want to wrap up with two more misconceptions. One is that only a customer surrogate or product owner can write them. The other is underestimating the power of the acceptance tests as a clarifying vehicle for the story.

Anyone on the Team Can (and Should) Create and Update User Stories!

I’ve seen the position of “only the product wner can write stories” taken time after time when I’m coaching agile teams. I’ll enter a Sprint Planning session and we’ll look at the Product Backlog. The team will complain about the backlog not being detailed enough or containing the ‘right’ set of stories. We’ll spend literally hours reviewing them and debating their intent until we run out of time in our time-box and need to reschedule the planning session.

Inevitably these teams point to the Product Owner as being the problem-complaining that they were not prepared.

As an agile coach I always challenge the entire team in these situations. It’s every team member’s responsibility and privilege to write and refine the stories on their product backlog. You see, user stories don’t simply capture ‘requirements’. Instead, they capture all work (let me repeat that) all work that will be undertaken by the team in order to meet the business’s expectations for the project.

Given this, it’s no wonder the product owner (or BA) can’t fill in a complete set of stories. Nor do they have the functional expertise that the team has in areas of software analysis and design, or development, or testing, or converging a product for customer use.

The user stories must be truly owned by the entire agile team. Sure, the product owner will probably spend significant time writing, refining, and ordering them. But consider that to be simply a “seeding pattern”. The stories aren’t truly complete until the team has iteratively refined them together. In Scrum and oft used term for this is – Grooming the Backlog. This is where the team gathers, either as a group or individually, and refines the stories encompassing the backlog.

Underestimating the Power of Acceptance Tests

Much of the focus of writing user stories is on the story-side or behavior-side of the card. Often there is little to no investment in developing acceptance tests (Confirmations) that are placed on the back of the card.

Why is that? My view is that defining test cases is hard for most teams to grasp. It’s sort of an afterthought and not everyone gets the intent or power of acceptance tests. I consider them more important than the user story description, and here are some helpful ways to view them:

Consider them mini-UAT tests at a story or feature level
They confirm Sprint Done-Ness from the perspective of the customer and the tester
They enable testers and BAs on the team to quantify key conditions that the software must meet
They drive the design and capability of the software; consider them defining the business logic for a story
They are a collaboration driver between developer(s), tester(s), BA(s), and product owner
They are either working or not; there is no in-between

There’s quite a bit of debate surrounding how many acceptance tests should be defined for each story. Certainly, they are not intended to exhaustively test the story-so they are not a complete list of test cases. I usually recommend somewhere between three and seven acceptance tests per story as determined by the team. One or two is certainly too few, and 25 clearly too many.

There is also debate surrounding how to phrase the acceptance tests. I’ve seen the following patterns for them across teams’ I’ve been coaching:

Verify that…”some behavior”
Confirm that…”again some behavior”
If I do this…this results
Under these preconditions, confirm that…”some behavior”

What’s important here, truly important, is not the phrasing, but that you define and confirm acceptance tests on a story by story basis. It drives quality collaboration and quality results within your agile teams.

Wrapping up – I hope I’ve clarified these four misconceptions and ultimately improved your user story writing.

Don’t forget to leave your comments below