Listen to the Software Process and Measurement Cast 304

Software Process and Measurement Cast number 304 features our interview with Jamie Lynn Cooke. Jamie Lynn Cooke is the author of The Power of the Agile Business Analyst. We discussed the definition of an Agile business analyst and what they actually do in Agile projects.  Jamie provides a clear and succinct explanation of the role and huge value of Agile business analysts bring to projects!

Jamie Lynn’s Bio:
Jamie Lynn Cooke has 24 years of experience as a senior business analyst and solutions consultant, working with more than 130 public and private sector organizations throughout Australia, Canada, and the United States.

She is the author of The Power of the Agile Business Analyst: 30 surprising ways a business analyst can add value to your Agile development team, which details how Agile business analysts can increase the relevance, quality and overall business value of Agile projects; Agile Principles Unleashed, a book written specifically to explain Agile in non-technical business terms to managers and executives outside of the IT industry; Agile: An Executive Guide: Real results from IT budgets, which gives IT executives the tools and strategies needed for bottom-line business decisions on using Agile methodologies; and Everything You Want to Know About Agile: How to get Agile results in a less-than-Agile organization, which gives readers strategies for aligning Agile work within the reporting, budgeting, staffing, and governance constraints of their organization. Also checkout,  Agile Productivity Unleashed: Proven Approaches for Achieving Real Productivity Gains in Any Organization (Second Edition)!

Jamie has a Bachelor of Science in Engineering Psychology (Human Factors Engineering) from Tufts University in Medford, Massachusetts; and a Graduate Certificate in e-Business/Business Informatics from the University of Canberra in Australia.

You can find her website here.

 

Next

Software Process and Measurement Cast number 305 will feature our essay on estimation (here is our essay on specific topics within estimation). Estimation is a hot bed of controversy. But perhaps first we should synchronize on just what we think the word means.  Once we have a common vocabulary we can commence with the fisticuffs. In SPaMCAST 305 we will not shy away from a hard discussion.

Upcoming Events

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested.

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Capturing requirements is different than catching fish.

Capturing requirements is different than catching fish.

Where do you get the requirements that make up your backlog? There are two classic macro strategies that project teams follow to gather requirements and create a backlog.  Where a backlog of requirements comes from and who was involved in the process has implications that can influence the whole life cycle of a project by setting expectations and identifying behavioral norms for the entire project.

The first macro category represents scenarios in which requirements are provided to the project team either fully or partially formed. This is very common for projects that are outsourced or in organizations where a significant barrier has been erected between corporate IT and the business.  The business decides what it wants and then negotiates to obtain what they are asking for.  In order for this scenario to work effectively, business departments hire business analysts (BA), create shadow IT teams or leverage super users to act as liaisons to IT.  The BAs, or proxy BAs, gather and document the businesses requirements, and then during the project execution, they interpret those requirements.  This type of behavior reinforces a barrier between the business and the team doing the work.

One of major problems this arm’s length process of gathering of requirements generates is an anchor bias in which the business’ expectations get set before they know what is possible.  The backlog becomes the baseline against which project success will be measured. Change and evolution become more difficult because changes would be perceived as renegotiating success.  Applying the Agile principal of embracing change and working with the business on a continual bias become significantly more difficult when the business has become anchored to the picture the initial requirements generates.  This anchor becomes even stickier when those requirements are codified in a contract or as success criteria in a charter (a weak form of a contract).

Another behavior that falls into this category is that the BA becomes a proxy for the product owner.  Proxy product owners don’t have the decision making power to change or evolve the backlog, so they tend to defend the status quo.  A better solution is to incorporate the BA into the project team with a true product owner.

In the second macro category the whole team, or at least a cross-functional portion of the team, gathers the requirements.  In an Agile project, the requirements are used to generate an initial backlog. Incorporating the requirements into backlog is an explicit recognition that the project will allow the requirements to evolve.  Involvement of a cross-functional team will produce better requirements earlier, while incorporating Agile principles and backlog concepts help parties stay less anchored to the initial requirements given the flexibility inherent unthreatening techniques. Removing or diluting the initial anchor makes it easier for the product owner to identify and incorporate the concept of a minimum viable product into release planning.  Without the anchor the project will not be perceived as all or nothing because the backlog can be re-prioritized or changed if needed.

The cross functional approach to developing requirements that includes business, BA, development and testing capabilities build bridges between IT and the business.  These bridges make it less likely that the BA will have play the role of proxy product owner, because business personnel have more exposure to the project environment, making it less foreign and frightening.

How the initial set of requirements defined and who participated in the process can have a huge impact on the trajectory of a project.  Whether organizations perceive IT as a partner or as a vendor will influence which requirements strategy will be most attractive, as will how dynamic the organization perceives the business environment. Partnership and dynamic environments tend more towards scenario two.  In the long run, all projects have to have a set of requirements. How we organize them will affect the how, who and when of gathering requirements.

Diane Zajac-Woodie

Diane Zajac-Woodie

Check out Software Process and Measurement Cast 278. SPaMCAST 278 features our interview with Diane Zajac-Woodie discussing the role of the business analyst (BA) in Agile.  Scrum is mute on the topic of the BA, does that that mean the BAs should pack their bags and look for re-training options?  Single word answer, no. The BA role is an important driver of facilitation and communication.  Diane clearly lays out not only what the BA should be doing in an Agile project but what is possible with a little facilitation.

Diane Zajac-Woodie (also known as @agilesquirrel on Twitter – explained in the podcast) has spent the last six years redefining the business analyst role as more than a requirements dictator. Through open and honest conversations, Diane guides her business partners toward creative solutions that solve problems and eliminate waste. She shares this same approach with her technical teams, facilitating communication, cooperation, and continuous learning to ensure success. Diane craves knowledge almost as much as chocolate and would make question-asking an Olympic sport. Her recent passion is to free those mired in the status quo even if she has to pull them out one at a time. Diane’s alter ego makes her thoughts transparent on her blog, http://agilesquirrel.blogspot.com/.

Diane is currently a co-chair for the Collaboration, Culture and Teams track for Agile2014.  She is giving her BA talk at Agile and Beyond 2014 in February and will be speaking at the Agile Development Conference West in June.

Remember to register for the “Influential Agile Leader” events led by Johanna Rothman and Gil Broza.  Check out the full details at www.InfluentialAgileLeader.com

Get in touch with us anytime or leave a comment here on the blog.  Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on Agile and risk.  Risk or risk management and Agile are topics that many might think of as an oxymoron when combined.  However in the SPaMCAST 279 we will show how Agile Risk Management can be used to improve the value projects deliver!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars.  The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.