Skip to main content

Tag: Team

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.

iseewhat1

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?

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:

  1. It’s ALL about the People collaborating around real working code!
  2. It’s about writing some more code to verify our presumptions in writing about the code…
  3. 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!

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


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].

Think “I” instead of “We” when Talking about Your Business Analyst Career

Picture yourself in an interview for your dream business analyst job. You are confident in your qualifications. You have prepared for the interview by researching the company, the hiring manager, and anyone else with whom you are meeting.

The manager asks you a few questions about your experience with a focus on business analysis. You answer confidently about how your team accomplished exactly what they were asked to do. You give an example. But the manager still looks at you a bit puzzled and probes for more information. She or he doesn’t seem to fully trust your answer.

One possible cause of this situation is that you are using “we” in your answers instead of “I”. You are a team player. You know that as a business analyst you help teams achieve great results. You focus your answers on what the team accomplished. This is a great way to look at your day-to-day work. But in an interview situation, the hiring manager is interviewing you not your team. Answers talking about “we” seem vague, are ambiguous, and can leave the impression that you are avoiding the questions.

From my own personal experience as a hiring manager for business analysts, one particular candidate among the many I interviewed with the “we” tendency, stands out among the rest. I share his story to help the other candidates out there who may unknowingly be facing his same challenges.

The candidate’s answers to my questions revealed a strong team orientation and other professional qualities that I respected and desired, but when it came to his BA qualifications, I couldn’t quite nail him down. In answer to every question about every project, he started the answer with “we”. We created a requirements document. We came up with an elegant solution. We implemented a successful project. We, we, we.

Truly liking the individual, I started probing and prodding then finally asked, “I understand what your team accomplished and that’s great. It’s important for me to understand what you contributed. What did you do, specifically, to help the team accomplish that success?” Unfortunately the candidate failed to come up with an answer and defended his “we” stance: “My contributions were only part of the team. That success was impossible without the whole team.” Although my gut said he was a good candidate for the position, I couldn’t validate his BA qualifications with any hard evidence. He was not hired.

I want to help you avoid this same shortfall. The difficulty is that his answer is true and valid. We accomplish more as part of a team. No matter how we think about it, we are not solely responsible for the outcomes we achieve as part of a group. But the career-defining questions remain unanswered: What did you do? Why should I hire you? Why should I believe that you will make a contribution on one of the teams in this organization?

In preparing to speak about what your team accomplished and what you contributed to help your team succeed, it can be helpful to keep a catalog of your projects and accomplishments. For example, let’s consider a requirements document. There is no doubt that significant project documents, such as a business requirements document or functional specifications, are the result of contributions from many individuals. When evaluating this experience for your contribution, think about the following activities:

  • Did you author the document? Alternatively, did you edit a document started by someone else?
  • Did you solicit feedback on the document and collate comments and reviews?
  • Did you elicit the requirements and ask the questions that ensured the document was complete?
  • Did you facilitate the meetings, pointing out disparate input or conflicting requirements?
  • What else did you do?

While the document you produced is the collective output of the team, it’s likely you had a very distinct role in that accomplishment. Catalog your specific contributions and be prepared to speak about them in detail.

Alternatively, if you were part of a BA team, you might consider quantifying your part in that team. For example, if the team collectively produced 50 use cases, maybe you drafted 20 of those use cases and provided critical feedback on the other 30. Can you think of an example where your feedback addressed a problem no one else had considered? Maybe you owned a part of the review or approval process. Maybe you owned the use case list and model.

Another way to think about this concept is to answer the following question: What hole would have been left if you had been plucked from the team? Looking at the team trying to achieve its objective without your efforts, analysis, and influence can help you see the situation with a fresh set of eyes. It can help you identify your slice in the team’s overall effort.

It’s also possible to use this approach to explaining your experiences while still showing you are a team player. One of the line items on my resume talks about a career experience from my early days as a QA engineer. I entered into a situation where developers across two different locations were often at odds with each other about the root cause of defects and who should fix them. I partnered with the developers from the other location, began testing their output directly, and helped drive more effective communication between the groups.

In my resume, I speak about breaking down communication barriers to reduce the length of time it took to resolve a particular category of defects. Of course, I did not single-handedly fix the issues, nor was I the only contributor to the improved success of this group of people. Every member of the team had a critical role in that improvement. But I am confident in calling myself out as the catalyst and talking about my role in bridging the communication gap, an accomplishment that helped carve my path into the business analysis profession.

So I ask you. What do you have to say for yourself and your career? Are you a career casualty to the ambiguity of “we”? If so, I challenge you to start a catalog of your recent projects and think long and hard about your contributions. This is a great step to take to advance your business analyst career.

Don’t forget to leave your comments below

What do BAs “Do” within Agile Teams?

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


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].