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

Leveraging Agile Market Research for Faster, Better Concept Optimization

Only one in 10 market-facing decisions have the backing of customer data.  Nowhere is this shortage of customer feedback more evident than in the concept development process.  It's no wonder that a significant percentage of product, packaging, and advertising executions fail every year.

The time and cost of traditional data collection methods have prevented researchers and marketers from tapping consumer insights as much or as early as needed leaving them to rely on intuition or gut feel to pick and refine winning concepts.

On-demand tools when coupled with the Agile Research Methodology allow researchers and marketers to identify and optimize winning concepts much earlier in the development process resulting in executions that are both faster to market and better performing.

An upcoming webinar presented by GutCheck, “Leveraging Agile Market Research for Faster, Better Concept Optimization,” on Thursday, November 14 at 2:00 pm EST will feature an interactive, step-by-step review of the concept development process infused with best practices for applying on-demand quant and qual tools using an Agile approach.

GutCheck is an on-demand research community solution that provides immediate insights from specific consumers with quality that is equivalent to traditional online communities. Unlike these offerings that challenge timelines and budgets, GutCheck enables an Agile Research approach that delivers actionable feedback in days instead of weeks and at 50-70 percent the cost of traditional in-person focus groups.

In this webinar Matt Warta, CEO, GutCheck and Lisa O'Connor, Lead Online Research Strategist, GutCheck will discuss:

• How to apply on-demand quant and qual tools within the Agile Research Methodology to screen and optimize concepts rapidly and early in the development process
• Common questions that yield rich insights for testing and refining concepts
• Best practices for recruiting and testing concepts with minimal bias
• An in-depth case study will also be provided to illustrate this approach in action.  We will reserve the last 15 minutes of the webinar for Q&A.

Reserve your webinar seat now: https://cc.readytalk.com/r/v8o7rwaiax7w&eom

Flashback Friday Flicks: Janet Bartz and Jane Shellum Video Interview

In the weeks leading up to the 2011 ProjectWorld® & World Congress for Business Analysts® Conference, we're looking back at some of our top content from 2010.

In the video below, Agile Scout's Peter Saddington interviewed PWWCBA speakers Janet Bartz and Jane Shellum on implementing Agile techniques at the Mayo Clinic.



Perhaps the biggest take-away from this interview: "Create an environment where it is ok to try something and fail."

Learn more about the Mayo Clinic session from 2010 by reading the full recap here.

Time is running out to join us at PWWCBA! Don't forget that readers of our blog receive an exclusive 15% discount off the standard registration rate with code PW11BLOG. Register today.

Playing Games With Your Team?

Yesterday I had the pleasure of moderating one of the Project World and World Congress for Business Analysts year-long learning web seminars. Our speaker of the day Peter Saddington (better known to those in the twitter world as @agilescout) was discussing key characteristics of an agile project owner.

As part of his presentation he mentioned the merits of playing games to get to know and better understand your project team. Two resources he pointed to for finding appropriate games for this were TastyCupcakes.org and GoGameStorm.com.

Have you ever turned towards interactive experiences like this to get to know a project team or work though a problem? What was the result? What game did you use? If not, looking at the two websites above, would you ever consider using this technique?

Share with us in the comments!

Michelle LeBlanc is a Social Media Strategist at IIR USA with a specialization in marketing. She may be reached at mleblanc@iirusa.com. Follow tweets from her and the rest of the Project World team @Project_World.

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. 

Project gone sour? How to set the course for recovery

We struck upon this article from PMTips. net and we'd love to share it with you. Brad Egeland writes that from his experience it’s very difficult to recover from a poorly planned or kicked off project; however, all is not lost. Egeland offers three ways to recover a good project that has gone sour.

• Work stoppage to re-plan

Egeland personally believes in – and finds the most success with – putting a work stoppage or major slowdown in place on a project that he has taken over is one of the quickest ways to assess the situation and inject some additional much needed planning. Of course, this additional planning would have been better served and cheaper had it happened at the beginning of the project. Undoubtedly, there is going to be some hit to the project budget and probably and even greater hit to the project schedule, but it’s far better to do this now than risk losing the project entirely.

• Adjust the schedule, reset customer expectations

The next option involves just accepting the problem and adjusting the schedule accordingly. If the customer isn’t interested in halting the project to perform necessary re-planning, then the next best option is to work hard to reset customer expectations on both schedule and budget and possibly on the quality of the end solution, but that will be a very very hard sell. Get the customer to understand there will be a delay and negotiate with them on budget issues to hopefully keep from having the plug pulled on the project.

• Add resources

Finally, the old “adding resources” option. Throw more bodies at it. Every seasoned project manager knows that this likely won’t work well. At best it gets the project completed well over budget and probably long past the original due date – hopefully salvaging at least some customer satisfaction. At worse it becomes a behemoth project that devours dollars and days faster than you ever thought possible and becomes about as effective as a BP oil spill disaster plan.

We encourage you to go to PMTips.net to discover how you can turn around project failure and keep stakeholders happy and well-informed. Our thanks to Brad Egeland for the great article!

What do you do when your project is the express lane to failure?

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?

Rally Software Teams with Oracle to Extend Agile Development and Application Lifecycle Management

EarthTimes.org reports that Rally has teamed with Oracle deliver the Rally Connector for Oracle® JDeveloper, extending the Application Lifecycle Management (ALM) functionality of Oracle Team Productivity Center to Agile development organizations. Oracle Team Productivity Center helps facilitate a productive team collaboration environment through the integration of existing ALM solutions, including Rally. is well-known for its leadership in Agile development, having won four Jolt awards for its Agile tools and with over 100,000 people downloading its Agile and Lean software tutorials. Oracle Team Productivity Center is an ALM tool for Oracle JDeveloper users. This combination of two market leading technologies for Agile ALM and Java Middleware brings a needed solution to teams leveraging Agile methods as part of their IT/SOA strategy.

Rally Software Teams with Oracle to Extend Agile Development and Application Lifecycle Management