Skip to main content

Tag: Agile

Embracing Agility – Your Best Bet for Business Analysis Skill Development!

Written by Robert Galen on . Posted in Articles.

If you’ve been reading my blog entries at all this year, you’ve realized that I’m fairly enthusiastic about the agile methods. I think one of the most misunderstood aspects of agility and the methods themselves relates to their nature. You know, they’re really not methodologies. Certainly not in the same sense as heavily documented Waterfall and its variants or RUP or Spiral or any other traditional methodology.

Instead, I liken them more to Lean and other improvement oriented thinking tools and approaches than a specific methodology. They also gather concepts and patterns from historical software development practices that seem to work well , e.g,  unit testing, continuous integration, refactoring, and pair-programming.  That’s why I almost always hear the following from my students in my classes: “So that’s agile. I’ve been doing much of that for most of my career. It seems that the packaging is the key…and the mindset.”

I find myself universally agreeing with the students’ perception. It’s about a mindset that transcends “agility” and leads towards outstanding performance and growth as a technologist. Let’s explore some aspects of that…

Self-Directed, Empowered, and Accountable Teams

If you get the chance to join an agile team as a BA, jump on it. It will give you a chance to operate as a true, collaborative team member. Leadership opportunities will surface and you’ll get plenty of opportunities to show off your chops in a very visible venue.  High performance is what matters in these teams, and low performers can’t “hide” from the team. It draws out excellence.

In these teams words, written or otherwise, mean very little. What counts is delivering on commitments with working, demonstrable software. It’s about real delivery! Not in hours worked, but in raw productivity and creative solutions to the teams’ problems.

Focus on Quality and Improvement

As part of their career evolution, BAs need to become much more “quality literate”. Dive deeply into understanding the techniques for building in quality, for example reviews and inspections. What are the business cases behind them? The pay me now vs. later trade-offs in software and begin to challenge poor decision-making.

Partner with the testers. They are often underestimated and underutilized within most teams.  Yet, effective testing is as challenging a technical exercise as architecting or modeling any software system. Dive-in and test the software with a wide-variety of manual techniques, and learn how to test effectively. Even jump-in and do some simple automation. It will give you yet another perspective in your journey!

And when you attend retrospectives, have the fortitude to engage your team on continuous improvement. Call them out on the practices that need improvement and, during each iteration, demand focus on those improvements. Then celebrate each and every improvement!

Transparency and Feedback

There is tremendous power in making all of our project dynamics totally transparent to everyone.  First, it takes courage to “tell it like it is”. It also opens the door for feedback from all perspectives. That old notion of not raising issues without solutions doesn’t hold any longer. We’d rather get early visibility into the issues so the entire team can engage in solutions.

And don’t get defensive. If you get confronted on a mistake, take the time to explain the context and thinking processes behind your decisions. Be open to corrective action discussions without appearing defensive. In fact, become more comfortable with failure. Failure is good in agile teams; we simply want to fail early, small, and catch it quickly. This leads towards the necessary adjustments to get things “back on track”.

Generalist Mindset

I’ve seen so many software development roles (programmers, architects, testers, BAs, project managers, etc) take a very narrow view towards their roles and their work. Very often they create a narrow silo of responsibility that they ‘own’ and everything outside of that is “someone else’s’ job”. That often extends to their knowledge as well. They might only understand one narrow slice of their applications and not have a broader brush view.

In agile teams this view is highly discouraged. Not so much by management, but by the very definition of a self-directed team trying to meet their goals and objectives. The broader your view, the more  flexibly you can operate within your team and deliver the goods.  Oh and by the way, the more valuable you become!

Wrap-up

Don’t let anybody tell you that agile teams are easy. They are not! To me they’re sort of a Boot Camp for personal growth and improvement. They provide opportunities for becoming more open-minded and trying new approaches. They also provide opportunities for thinking outside your traditional box and roles. If you’ve got the courage and persistence to truly want to improve, agility will provide you with incredibly diverse opportunities to learn, be recognized, and advance!

That is…if you embrace It!

Don’t forget to leave your comments below

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

Written by Robert Galen on . 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:

  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]

How Can BAs Be More Strategic in an Agile Environment?

Written by Maria Horrigan on . Posted in Articles. 1 Comment on How Can BAs Be More Strategic in an Agile Environment?

As a business analyst working in the business area, I am finding myself more involved in the enterprise strategy arena and working across many projects. More and more, these projects follow an agile methodology. I’ve been traveling a bit lately and needed some reading material for my trip so I thought I’d revisit Sun Tzu’s The Art of War.

The Art of War focuses on strategy and planning and in an agile environment, there is much insight and wisdom BAs can gain from this sixth century BC Chinese General. Here are just six of his ideas that I think most capture the essence of agile as a philosophy and the core business analysis competencies I have been using on my projects, to help me adapt to an agile framework.

1. Discipline and Control of the Game – “…marshalling of the army in its proper subdivisions, the graduations of rank among the officers, and the control of military expenditure”¹. When I am presenting on Agile, one of the criticism I get from the audience is that Agile lacks rigor and discipline and is a more laissez-faire approach. I suggest to them that even though Agile fosters innovation and creativity, the project’s success is not the result of luck or a fortuitous accident, but rather the result of consistent planning and effort. On my projects, everybody’s role is clear and each knows what we need to do to get to the next stage or complete the next stream of work. My BA approach on Agile projects is iterative, as a team we learn and adapt as we go, but that doesn’t mean there is absence of planning and coordination.

2. Be Flexible and Run with Opportunities – “Avail yourself of any helpful circumstances over and beyond the ordinary rules. According as circumstances are favorable, one should modify one’s plans”¹. Sun Tzu was known as a master of controlling the game through leadership and discipline, but in this passage he is referring specifically to this need to remain flexible in changing conditions and be prepared to capitalize and follow up on an opportunity. This is the essence of Agile. When we commence projects, it is not possible to know all we can about the environment, the business and user needs. Requirements will change and evolve as we progress through the project and learn more about the situation and context. As a BA we must have a focus on continuous learnings and applying these learnings to the next stream or iteration is the key.

3. Act Fast to Avoid Fatigue – “Though we have heard of stupid haste in war, cleverness has never been associated with long delays”². Protracted campaigns can damage morale and resources and Master Sun suggests taking swift action to avoid the pitfall of expense and exhaustion. A number of years ago, I worked on a project that had already been going for two years when I joined. People were clearly tired and weary from the ‘battle” and project costs were blowing out. We regrouped and adopted an Agile approach. We had stand-up meetings every day within our team but we only engaged users when we had some progress in our work to show as these users and business groups were fatigued after two previous years of consultation with nothing to show for it. Within six months we had a working prototype from end to end, and a strong and committed BA and design team that rallied behind the Change Manager leading the project. It was important that we had “quick wins” early to keep the momentum towards our goals and manage the change process from “as is” to the “to be” state. Having a change manager to help facilitate and progress requirements through the various governance members was a big advantage.

4. Ensure Your Goals and Objectives are Realistic – “…by commanding the army to advance or to retreat, being ignorant of the fact that it cannot obey”². I think this really speaks to the heart of the user-centered design focus of many of my Agile BA projects. Master Sun warns that mistakes will be made if orders are issued from the safety of a far off court that doesn’t have experience of the combat situation. The business context and “big picture” strategy need to be mindful of the day-to-day operations. The people who are on the ground and know the capabilities of the current team and resources are the best source of knowledge for work shopping the business drivers, processes and gaps in order to uncover the business and user needs for your project. This is where BAs have a key strength and knowledge base. For example, once I have captured these needs, I always talk to the technical team to see if what the users want is realistic and possible (within out budget and capability). If there are sound limitations to what is possible, then I go back to the business and users and discuss alternate ways to achieve the same goal. Users then give me insight as to whether this alternate idea is practical. This iterative approach is critical to solving some of the more complex issues on the projects.

5. Employ the Right People for the Job – “… by employing the officers without discrimination, through ignorance of the military principle of adaptation of circumstances. This shakes the confidence of the soldiers”³. Finding the right people for the job is imperative. In Agile projects it is important to look at the essence of what the project is about and what problem it is aimed to solve and then decide what skills are needed and what patterns to apply. From this planning we then look at building the team. Of course you do not always have the luxury of being able to pick your team for projects, but if you set up an Agile team and draw from skilled resources across the organization, this is more likely to aid the success of your project. Reverse engineer the position; don’t just look at who you have and see if they will fit, find out what you need and then seek people with these skills and abilities. BAs bring many skills to the project and in Agile I have found that my skills of analysis are used beyond traditional requirements gathering. I have been involved in design, information architecture and business strategy workshops.

6. Adapt as Strategic Rigidity is Dangerous – “Water shapes its course according to the nature of the ground over which it flows; the soldier works out his victory in relation to the foe that he is facing”4. This emphasizes the need for fluidity and that to be successful, you must adapt. The business environment is dynamic and constantly changing and adaptation is key. As Charles Darwin stated “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change”. As BAs in an Agile environment, you need to understand your user (primary, secondary and tertiary) and ensure that your processes and systems are developed with their needs in mind. When building user personas, start with a “skinny” view of this user and flesh it out as you find out more about their needs. Likewise, your business requirements will be “skinny” at the commencement of the project and will be elucidated more as the project progresses and each stream build upon the knowledge of what is working and what is not.

As an enterprise BA I am looking not just at my immediate project, but also how this work fits into the rest of the organization. Sun Tzu stresses the need to plan, find the right people, and give them resources and authority to execute those orders, choose a strategy and vary your tactics according to the situation. In looking at the essence of your projects, take the time to plan what you need in terms of skills, patterns to apply, things to do and things to produce and be flexible in your approach to adapt these to the project learnings as you progress, or the business needs or circumstances change.

References:

SunTzu’s Art of War, A 52 Brilliant ideas interpretation by Karen McCredie, 2008

¹The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 1 – Laying Plans

²The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 2 -Waging War

³The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 3 – Attack by Strategem

4 The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 6 – Weak points and Strong

Don’t forget to leave your comments below

Maria Horrigan is an experienced business manager, IT strategic planner and information and communications specialist. She has over 10 years senior management experience within the pharmaceutical industry, not-for-profit and Government. As a principal consultant, Maria is an experienced information architect, senior business analyst and IT strategic analyst and provides advice on developing system requirements with a focus on information architecture and user-centred design, to ensure appropriate IT systems are intuitive and usable. She is a senior practitioner and a well-known Australian speaker on communication, user-centred design, and business analysis. She has experience managing large federal government contracts and project management of large scale business system implementation, systems planning, and analysis and change management. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. Maria is a Board member and Vice President of Women in Information and Communication (WIC).

The State of Requirements Management

Written by John Simpson on . Posted in Articles.

Goodbye 2009, Hello 2010!

For many organizations, 2009 simply can’t end fast enough. The brutal economy made for a tough year, there’s no denying that. However, taking a moment to reflect on things from a business analyst’s point of view, I believe there are a few bright spots to celebrate. Consider them the signs of hope for a better 2010. In this article, I want to highlight three trends we first saw emerge from The State of Requirements Management Report we published back in June 2008 on the challenges, trends and solutions happening in software product development. In that report we surveyed 200 organizations and explored topics such as:

  • What are the biggest challenges in innovation that companies face?
  • Is the Agile process over-hyped?
  • How does collaboration apply to requirements management?
  • What frustrates people more – scope creep, unrealistic expectations or lack of testing?
  • Which genre of music is most popular? OK, that one we threw in just for fun.

I never anticipated the kind of response that report would get, with over 18,000 downloads of it since we first published it, but in hindsight I think it struck a chord with people, especially those in the business analyst community, shedding light on some of the challenges we all deal with day in, day out. You can read the full report and compare the results to what you experienced this year. I would be curious to hear your thoughts and experiences. http://www.jamasoftware.com/media/documents/State_of_Requirements_Management_2008_Jama.pdf

As I look back on 2009, the three positive trends I saw emerge which will carry over into 2010 include:

1. Greater Respect and Appreciation for the Business Analyst Role

Understanding what the customers need and documenting all the requirements isn’t easy. In fact, these were the top challenges based on feedback we saw within The State of Requirements Management Report at 65% each.

stateofreq1

As it becomes more apparent to executives and senior management that requirements are the building blocks of innovation, the respect for the people whose job it is to manage requirements increases. Can you say “Christmas bonus”? And, I’m not talking fruit cake; give the BAs you love something good this year!

In all seriousness, this heightened appreciation for BAs is also reflective in its being an area of job growth, despite high unemployment rates in other sectors. Essentially, if you have strong business analyst and product management skills, you are in high demand. Feel good about that for a moment, now put down the eggnog and get back to work. You’re only as good as your latest specification, right?

2. Greater Accountability for the Requirements Shared by the Entire Team

Collaboration has been a hot trend in product development for a few years now. But, what does that really mean in terms of results? One of the lesser known benefits of better collaboration is that over time you see an increase in accountability across the entire team for getting the requirements right and building the products to spec. That’s a good thing for everyone. How often before did all the responsibility fall just on the shoulders of the business analyst or product manager to define the set of features and write gorgeous requirements that would be magically understood and implemented flawlessly by all?

stateofreq2

Truly collaborative teams embody this shared accountability which raises the bar for everyone involved, whether it’s your job to listen to the customer and capture the requirements or interpret the detailed requirements downstream to code and ensure the functionality is right. When everyone contributes to the development of the requirements, the success rates increase dramatically.

If your team doesn’t embody this characteristic now, you might want to make it a priority in 2010, or hope for a miracle bag of requirements pixie dust from Santa. I think that’s high on the wish list right after the Wii and Twilight stuff.

3. Agile is More of a Mindset than a Development Process.

Man, there was a ton of attention given to Agile again this year. Agile conferences. Agile books. Agile processes du jour. I think I’ve contracted “Agileitis”, the rapidly, contagious disease that can be spread from the “pigs” to the “chickens” in a Scrum daily stand-up meeting… I know there’s a bad Swine flu / Bird flu whopper of a joke in there somewhere.

The key point is, Agile isn’t just a flavor of development process. It’s a core philosophy – a cultural mindset of embracing change, inviting the voice of the customer into your process throughout, and designing workable software that is continuously improving over time. Call them releases, iterations, sprints, milestones – whatever you want. The labels are less important than the outcome of the products you produce. The evolution I saw emerge in 2009, and will continue in 2010, is the concept of a “hybrid” approach where mature companies merge disciplined requirements management practices for proper planning and requirements documentation, with the freedom for developers and testers to adopt more agile, lightweight methods to build and test new releases. It’s the best of both worlds.

stateofreq3

I’ve seen many companies be successful with a hybrid process, and one of the reasons it’s more prevalent now is that the tools available today are designed to flex to support whatever process or processes work for your team.

Big picture – the goals are the same – build great products faster, cheaper and with higher quality. My recommended New Year’s Resolution: Adopt whatever mix of processes, people and tools you need to achieve your goals, demand and accept nothing less, and you’ll have a great 2010.

Looking ahead to January – Share Your Voice.

In January, I’ll be conducting the 2010 State of Requirements Management Survey and would love your participation. That way, we can establish an annual benchmark study for our industry on what’s real and what’s hype, and see what others are doing to be more successful managing requirements. So look for that after the holidays.

On a personal note, from my family to yours – I’d like to wish everyone and their families – happy holidays and best wishes for a prosperous new year! See you in 2010.

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware.

Agile BAs… Don’t Go in without TOOLS!

Written by Robert Galen on . 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

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