Agile State of Mind

Are you wondering how to choose which project management method to deliver a successful project? Organizations today have to be more competitive in the marketplace so choosing the best practices and methods for your organization and projects is important. Agile is a set of values and principles, not a pre-defined process with obvious areas of limitation. Waterfall is a model based on development method that is linear and sequential.

Here are four criteria to choose the best fit of methodologies at the right time for the right customer.

1. Time to market projects – Agile adoption has replaced waterfall in organizations in the delivery of small, yet frequent pieces of functionality where requirements are expected to evolve, change is embraced, competition in the marketplace is a key concern, and critical to delivery of the latest technology. I.e.: medical device manufacturing, military/aerospace.

2. Status quo – Waterfall is a better choice for organizations that are not flexible, have clearly defined requirements, frequent interactions with end users and other stakeholders is a constraint or when there is risk of key developers quitting the project midway.

3. Success criteria – The success of a project that is defined by delivering business value will benefit from agile methodology. The success of a project defined by measured by KPI of the IT organization would be better suited with a Waterfall methodology.

4. Organizational Project Portfolio – Organizations that have a diverse portfolio must be both risk adverse, innovative and take some risks to be competitive.  Choosing a hybrid approach to use a blend of both methodologies would be beneficial. Planning, requirements and team communication are areas in which organization are designing custom best practices/ methodologies that fit their culture.



Action Items to Help You Get Started:

> Choose your methodology wisely; make sure your project team can adapt to the change and lead using the right best practice methodology or a hybrid approach.

> Focus on team member selection – Resources on an agile team can thrive by co-locating in common areas or resources can struggle due to intense and constant interactions which may create stressful team dynamics.

> Leadership Support – all projects need great sponsors, buy in from the business for implementing IT standards and methods and support for product service delivery using a big bang approach to smaller iterative delivery cycles.

Ultimately, a hybrid approach of traditional waterfall and agile elements make be your key to success. A hybrid approach can help an organization leverage talent and deliver business value early and often for software development projects.

ProjectWorld & World Congress for Business Analysts 2014, is taking place in Seattle, Washington September 22-24th at the W Hotel. The 2014 program is designed with courses for all training levels, a robust agenda, and most importantly tangible lessons which you can begin implementing the day you return to your office, making you even more valuable to your organization. PW&WCBA offers attendees 36 PDU/CDUs - that's more than half of the required credits necessary to maintain your certification in just one place.

To learn more or register for the event, click here: http://bit.ly/1jtZtxB
- See more at: http://www.iirusa.com/projectworld/speakers.xml

Live from #PWWCBA: Structured Conversations to Deliver Value

It was fortuitous for me that I chose to attend Ellen Gottesdiener's final session of the day "Powerful Planning, Agile Analysis: Structured Conversations to Deliver Value" as it involved an in-depth use of the Project World website as an example of finding value for customers/users.

We identified many different possible users for the site:
attenders
vendors
bookers
reviewers
approvers

(Ellen's tip: give each user type a name that describes what they do, not a job title, things ending in "er")

Each of these users has different requirements priorities such as: register securely, ease of use, find out attendee numbers, see a business case showing ROI of attending the event. You can perform discovery to find out what your users need through steps such as interviews.

These requirements can then be a means to the end of finding value.

So, what would your requirements be for the 2012 ProjectWorld® & World Congress for Business Analysts® website?

Ellen Gottesdiener - Agile Retrospectives

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

A retrospective is a ritual in which the project community:

Reviews the iteration/release/project story

Harvests the collective wisdom of the team

Tells the truth without blame or judgment

Identifies what to appreciate and improve

Understand and forgives its failings

Relishes in its successes

"The insights gained from the retrospectives are the basis for starting again."

What do we ask during a retrospective:

What did we do well that we might forget to do next time if we don't discuss it?

What did we learn?

What should we do differently next time?

What still puzzles us?

What needs more discussion?

Retrospectives need to have structure to them, but also flexibility to move and respond to changes:

Readying - Set the stage

Past - Gather data

Present - Generate insights

Future - Decide what to do

Retrospect - Close the retrospective

In retrospective of this talk, Ellen did a great job helping us understand a framework for holding a retrospective. To learn more about retrospectives you can visit Ellen's website at www.ebgconsulting.com.

Wisdom from Our Speakers Day 1 PWWCBA 2010

Here is a quick recap of Day 1 from the awesome speakers at Project World 2010






"Core of Agile is resurfacing and advocating business value." - Susan Block

"It's ok to do Agile with a little "a" try things if they work or throw them out. Only use pieces that work or provide value." Jane Shellum

"Be open to what the teams are saying. They come up with great ideas on how to do things." - Pam Johnson

"Make it ok to fail." - Janet Bartz

"If a problem arises, ask the team." - Dave Grabel

"Be Agile, don't just use Agile." - Manoj Vadakkan

Find out more about this event by opting into the email newsletters: Sign Up ProjectWorld

[This article was originally published at AgileScout.com.]

Questions for Our Panel Speakers

Including:

Manoj Vadakkan

Susan Block

Dave Grabel

Janet Bartz

Jane Shellum

Pam Johnson

Question: How do you make sure that Agile isn't used as a fire extinguishing tool?

Answer by Pam Johnson: Understand the priorities first, go from there and don't fight fires.

Question: Where do you start estimating? How do you kick off the process?

Answer by Manoj Vadakkan: Estimation should continue as is if it's working. Try small projects and iterate on them.

Question: Can a project be too Agile? Moving ahead without enough requirements definition?

Answer by Manoj Vadakkan: It's like an iceberg. You start at the top (prioritized), and as you get deeper it can get bigger. That's fine.

Question: How can Agile techniques for integration and package delivery?

Answer by Susan Block: We have to understand how integration as a product is brought into development. Analysis exercise to elicit the stories to deploy the configuration or integration. Need to have stories to cover that work.

Question: Multiple customers and conflicting priorities? Does Agile work?

Answer by Pam Johnson: Bring all product owners in and have a prioritization session. If that doesn't work, escalate it up towards higher level.

Question: Is it possible to perform Agile business analyst tasks even when project is still formally waterfall?

Answer by Susan Block: I recommend that you look at your big requirements phase and break it down into prioritized functionality. What will add the most value? Maybe you can make the case to provide just enough requirements instead of "all."

Question: Does Agile make sense for projects without a major customer facing component?

Answer by Pam Johnson: Yes. Customers are whomever you're doing the work for. Can be internal.

Question: How do you get team members to work outside their primary skillset to enable swarming?

Answer by Susan Block: Very hard to do, but try leveraging a bonus criteria for team members who are stepping outside their role. Give a carrot of promotion or rewards as a motivator.

Question: Does the business have to colocate with the development team?

Answer by Janet Bartz: Shadow the business people. My personal view is you have to have the business people with IT. It's so much more powerful. You can feel that somethings different where we are. It's tangible. Forget the throw-it-over-the-fence mentality.

Question: Executive support and Agile. What actions would you recommend for teams who want to move to Agile but don't have the support of upper management?

Answer by Manoj Vadakkan: Ask the business the question of why they want to go Agile and what are the reasons?

Question: What kinds of IT software initiatives are not Agile-appropriate?

Answer by Susan Block: Support issues and infrastructure projects that are cut and dry.

Question: How do you get the business to let go of big business requirements documents?

Answer by Jane Shellum: Nobody likes fat requirements documents. They come out of fear of not having all your bases covered. Easy to let go once you understand how Agile works. No such thing as scope creep. Scope change. Then prioritize the total list.

[This article was originally published at AgileScout.com.]

Pam Johnson on Self Organizing Teams

Pam Johnson works with Scripps Networks Interactive and they have been doing Agile for 3 years with 30+ development teams.

Pam describes a well understood and fully functional Agile enterprise. A very good example of how Agile is done successfully in a large organization with many teams.

This was an interesting talk because Pam gives the audience a view of a very successful Agile enterprise. There were some interesting points to take away but many of the points were covered by previous speakers.

Pam's talk was a nice end to the main speakers in that it gave us a refreshing look at a very well oiled Agile enterprise. We hope for continued success for Pam and Scripps Network!

Some of the changes that the Scripps Network needs to continue to improve include:

1. Better defined project initiation processes
2. Improve turnaround time for obstacle clearing
3. Leadership coaching within teams
4. Continued efforts to move from transactional leadership to transformational leadership
5. Continue to mature relationships with development teams
6. Get more granular with regard to defining roles and responsibilities for project managers, team members, and functional managers
7. Continued cross training - Become more generic and less heroic

[This article was originally published at AgileScout.com.]

Janet Bartz and Jane Shellum on Using Agile and Lean Methods

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

Janet and Jane come from two different areas of business for the Mayo Clinic. It's the business and IT joining forces!

"When the business and IT partner together value can be derived through collaboration." - Jane Shellum

The Mayo clinic employs several Agile techniques on their projects. They started by focusing on what it took to deliver value, used some (not all) Agile concepts, and built a "dream team" that would fill the Agile roles needed to ensure the project would move smoothly. 

The roles they created included: 

1. Solution Architect 
2. Business Architect 
3. Application Architect 
4. Data Architect 

"If what I have in the end is a shelf full of documents and no software - I have failed." - Janet Bartz

What is interesting about their experience is that even though their project is Agile, there are still remnants of the old waterfall method that are still necessary. Going Agile doesn't mean drop (all) the old ways of doing things! 

What was also nice was a section on things that they are aware of that need improvement:

• Technical debt reduction
• Keeping technical architecture in mind
• Some Keepers and Kudos from Janet and Jane include:
• Adherence to fixed iteration schedule
• Poster-sized schedule of features and sequence
• Commitment to quality and testing early
• Inclusion of senior software QA engineer from the beginning

In summary, the business and IT partnership is critical. Don't forget the basics of open, honest and transparent communication with leaders and teams, embrace change but manage it, recognize accomplishment, and finally, be Agile, lean, and in-control.

Dave Grabel - Globally Distributed Teams

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

Introduction

Dave is a "recovering command & control manager!" Nice to see a little bit of transparency in the beginning. Before Agile Dave lead effective waterfall processes. So what is the reason to go to Agile?

"Change was impossible midstream."

A Tale of Two Projects - Flipping the Agile Manifesto

Two projects that Dave is working on use Scrum, but not completely. 

1. Project A was a project team of 25 people converting classic ASP to ASP.net offshore. - Successful project.
2. Project B was a project team of 150 people doing over 1000 Visual FoxPro screens converted to JSP web pages using BEA web portal offshore. - Failed project.

"Agile can be wrong, but it should only be wrong for two weeks. Because you retrospect every iteration."

If teams turn the Agile Manifesto on its head, it becomes ScrumBut. 

Dave gives us an interesting story about the two projects and told us the differences between the two teams. It was an interesting take on how to contrast successful vs. failed projects for distributed teams. 

"You can handle change by being responsive to the stakeholders needs, that's what Agile is all about."

The biggest takeaway would be that to work with overseas teams or distributed Agile teams, there needs to be some very solid processes in place to ensure your team is communicating and collaborating daily.

Susan Block - Agile Requirements

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

Introduction

• We will learn about Susan's transition from waterfall to Agile as an Agile business analyst
• Understand the differences for the requirements approach on an Agile project.
• Integrate best practices on an Agile project.

The Vanguard Group went Agile to shorten implementation cycle and to deliver most valuable features first. Makes sense to us, a great reason to go Agile!

Agile for Vanguard Group is:

"Better, Faster, Cheaper."

As an Agile business analyst, Susan tells us that back in 2007 a enterprise initiative was funded for a multi-year program and went Agile halfway through!

A life before Agile business analysis for many projects looks like:

• Project Charter
• Estimate requirements up front
• Negotiate requirements duration
• Produce a project plan for requirements phase
• Conduct requirements sessions
• Document detailed requirements in templates
• Go through a change control board for changing requirements
• Handoff to development team

After transitioning to Agile, Susan's team found that:

• Processes are responsive to change with iterative planning and smaller units of work.
• The teams have daily communication
• The teams are cohesive in that they are committed, accountable, and available
• During the transition, Susan's team stopped cold turkey their old ways and went Agile. Interesting point here!

Agile at Vanguard has successfully transitioned to Agile over three years and developed Agile training curriculum in-house! This is a great success story!

The biggest takeaway here is that it takes time to transition to Agile, three year transition is not to shabby.

Manoj Vadakkan on Agile Project Management Estimation

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]


There was a Time Before Agile: 

Before Agile most shops "gathered" requirements from the beginning.

UAT usually was an afterthought and usually left behind in the development process and estimation was done long before the work was even initiated. 

"The actual work always took longer to do than estimated."

Taking baby steps towards Agile:

• Start small with baby steps in fixed sprint length
• Run tests after each iterations
• Start estimation through user stories
• Get customer feedback

Manoj uses the following Estimation Techniques for User Stories:

• Planning Poker 
• T-shirt sizing 
• Ordered piles 

Manoj defines "Velocity" as how many story points a team can complete within an iteration.

How do you average your velocity?

1. Take out outliers (highest and lowest velocity #)

2. Take best velocity (after outliers taken out)

3. Take lowest velocity (after outliers taken out)

4. Have conversation with your customer around the lowest and best velocity after taking out the outliers. 

Making a Leap to Agile Requirements

The upcoming PW&WCBA 2010 event has a pre-conference track devoted exclusively to agile. Learn from veteran PMs about what it really takes to be agile. Check out the session with Susan Block.

Susan Block is a Lead Business Systems Analyst for The Vanguard Group and in this session, "Making a Leap to Agile Requirements," attendees will learn how to transition their requirements approach from a traditional waterfall project to an Agile project. This presentation will focus on what’s different, what’s the same, how to apply the Agile Manifesto principles to requirements, and best practices from the “front lines” of agile requirements.
Learn how to transition from waterfall to Agile, what to do differently for requirements in an Agile project, and how to integrate best practices on an Agile requirements effort.

Join Susan at 11am on Monday, November 8th.

For more information about the Agile track and the other presentations at PW&WCBA, please download the event brochure.

Complimentary Webinar: Proud's and Sorry's for Agile Project Management and Business Analysis

Date/Time: Wed, Sep 22, 2010 12:00 PM - 1:00 PM EDT
Register: https://www1.gotomeeting.com/register/332931945

Get a preview of the new Agile Summit taking place at the Project World® & World Congress for Business Analysts® when some of our Agile Summit speakers share a taste of their journey to agile. In a matter-of-fact roundtable style, your Summit speakers-- representing a cross-industry managers and analysts on the front lines-- share their “prouds” and “sorrys” of transitioning to agile.

The roundtable discussion cover four unique themes:

• Delivering Value
• Teamwork and Collaboration
• Technical Practices
• Communication and Change

Facilitated by agile coach and requirements expert Ellen Gottesdiener, join us to learn essential kudos and regrets from your industry peers who are in the midst of making agile work in their organization. Don’t miss this freewheeling yet frank exchange.

Roundtable Participants:

• Manoj Vadakkan, Agile Coach/ Release Manager, CGI Federal
• Susan Block, Lead Business Systems Analyst, The Vanguard Group
• Janet Bartz, Head of Section, Information Technology, Education Support Systems, Mayo Clinic
• David Grabel, Director, Applications Development, Monetrics

Moderated by Ellen Gottesdiner, Founder/Principal Consultant, EBG Consulting, Inc.

Register for the webinar below
https://www1.gotomeeting.com/register/332931945

What does a Scrum Master do?

While many of you may be clear on the roles when moving to Agile, we thought it would be fun to tackle the role of Scrum Master. While researching today we ran across Steve Novoselac's blog and a recent post on Agile roles.

Here's what Steve had to say:

But what does a Scrum Master do? Well a lot of it might depend on your process and team but here are a few things (there are probably a hundred more)..

* Facilitate the Daily Standup/Scrum
Each day when you meet for your 15 minute standup, the Scrum Master should make things start on time, and keep flowing, and make sure people are answering the 3 questions (What I do today? yesterday? What is in my way?). The Scrum Master should cut off people from going long, make sure things get tabled or moved to a hallway discussion instead of taking of everyones time.

* Make sure the Burndown/Velocity is being tracked
The charts! Of course, someone needs to make sure the metrics are being tracked and also displayed. Now depending on your team, it might just mean .. well, nothing but making sure do’ers are updating their burndown correctly. You might have virtual charts. But in some teams, you might need to print the charts for the board, or you might even need to add the burndown yourself depending on your process/system. Keeping track of these metrics is key. You want to keep people informed of your progress every day (at least for the burndown – I like to track velocity as a bullet chart for the sprint and update each day as well).

* Get all the Stories Ready for Planning
In some teams, the scrum master might be the only person doing this, in others there may be a group of analysts, etc. But the Scrum Master should be sure to have the stories ready for planning, to score and discuss. Your team probably has a backlog of bugs, features, enhancements, technical debt, and it should be prioritized, but the Scrum Master should be where the buck stops to make sure everything is in order for planning.

* Facilitate Sprint Planning
Just like facilitating the daily scrums, the Scrum Master should facilitate the “Sprintly” Sprint Planning meetings. Review, Retrospective, Scoring. Keeping things moving, being an observer but not really a decision maker – that is for the team to do.

Check out the rest of the Scrum Master's role over at Steve's blog.

After reading through the role of the Scrum Master - what other job functions may be missing?

Free Web Seminar - Navigation Tips for Exploring the IIBA BABOK 2.0

Date: Wed, Oct 7, 2009

Time: 2:00 PM - 3:00 PM EDT

Have you ever gotten lost when traversing through the IIBA® BABOK® 2.0? How quickly can you find pathways through the Guide? How easily can you trace your way from one key element to another? Whether you are new to the discipline of business analysis, someone studying for the CBAP® or even a seasoned business analysis professional, navigating through the BABOK® can be a daunting task.

In this webinar we’ll explore a variety of pathways through the BABOK. Your navigator for the session is requirements guru Mary Gorman, a four year veteran of the IIBA Body of Knowledge Committee.

IIBA® International Institute of Business Analysis®
BABOK® Business Analysis Body of Knowledge®

What you will learn:

• Visualize the underlying foundation of the BABOK® (knowledge areas, tasks, techniques and requirements models)
• Trace foundation elements throughout the BABOK®
• Apply analysis modeling techniques to navigate the BABOK®

Speaker:
Mary Gorman, CBAP™, Senior Associate at EBG Consulting, assists teams to build the right product through exploring, analyzing and confirming their requirements. Mary has over 25 years experience as a consultant, mentor, trainer, facilitator, process engineer, developer, and analyst. In addition to serving on the IIBA Body of Knowledge Committee, Mary also helped create the certification exam for the Certified Business Analysis Professional™ (CBAP™).

Register below, mention priority code M2120W3BLOG
https://www1.gotomeeting.com/register/974065696.

This web seminar is presented to you by:

Webinar Recording Available: Agile Requirements (Not an Oxymoron)

Complimentary webinar recording of, ‘Agile Requirements (Not an Oxymoron)’ with Ellen Gottesdiener, Principal Consultant and Founder of EBG Consulting is now available online:

https://www1.gotomeeting.com/register/810361744

In this Webinar, requirements expert and agile coach Ellen Gottesdiener will describe how agile and requirements combine to form a sound and sensible union. You will learn how business analysis and requirements practices really work on agile projects; ways agile teams represent, verify and validate requirements; and how effective agile teams collaborate around requirements. Join us to learn how agile requirements provide the engine that drives successful delivery of business value.

What you will learn:
•Understand the agile method of developing requirements
•Describe business analysis and requirements practices that change on agile projects
•Understand agile adaptations to “traditional” requirements practices •Appreciate the value of requirements analysis on agile projects
•Enumerate the ways requirements form the basis for planning on agile projects

Complimentary Webinar: Agile Requirements (Not an Oxymoron)

Space is limited.
Reserve your Webinar seat now at:
https://www1.gotomeeting.com/register/810361744
Please mention code: G1M2120W1BLOG

Traditional approaches of requirements seem to contradict how agile teams might approach requirements. Misconceptions abound about how agile projects develop requirements and whether they even do analysis. In practice, agile projects use requirements as the basis for planning, development and delivering business value.

In this Webinar, requirements expert and agile coach Ellen Gottesdiener will describe how agile and requirements combine to form a sound and sensible union. You will learn how business analysis and requirements practices really work on agile projects; ways agile teams represent, verify and validate requirements; and how effective agile teams collaborate around requirements. Join us to learn how agile requirements provide the engine that drives successful delivery of business value.

What you will learn:
•Understand the agile method of developing requirements
•Describe business analysis and requirements practices that change on agile projects
•Understand agile adaptations to “traditional” requirements practices
•Appreciate the value of requirements analysis on agile projects
•Enumerate the ways requirements form the basis for planning on agile projects

Speaker:
Ellen Gottesdiener, Principal Consultant and Founder of EBG Consulting, is an internationally recognized trainer, facilitator, speaker, and expert on collaborative requirements development. Ellen’s company provides high-value training, facilitation, and consulting services to agile and traditional teams. An agile coach and trainer with a passion for agile requirements, Ellen works with large, complex products and helps teams elicit just enough requirements to achieve iteration and product goals.

Ellen’s book Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Her second book, The Software Requirements Memory Jogger, is the “go-to” industry guide for requirements good practices.


Title: Agile Requirements (Not an Oxymoron)

Date: Thursday, April 30, 2009

Time: 2:00 PM - 3:00 PM EDT


After registering you will receive a confirmation email containing information about joining the Webinar.