Information Radiators - How to Heat Up Your Team (A Fictional Story of Success).

Discovery
Recently I was asked to drive a new software development project with a project team that has been working together for more than a year. Management direction to me? "We want you to use Agile!"

After spending some time with the leaders on the team, I found myself in a challenging situation. The team, while possessing amazing talent, had no focus or organization. The team members were application developers, business analysts, and system testers. They didn't know what they were working on for more than a couple of days. Additionally, the product owners (yes, there were 15 of them) were spending too much of the team's time making decisions about what features were a priority.

Initiation
I went to work. I reserved a conference room for the team, built a Kanban board, and started training the team on the basic principles of Scrum. Additionally, I scheduled a meeting with the product owners and coached them on the importance of having a single voice when communicating to the team. We identified a chairman to attend our daily Scrum meetings to act as product owner. The chairman would meet with all of the stakeholders, collect their stories, and bring those to the team with a single voice.

Kick-start
Our first daily Scrum is today! I walk into the conference room with the Kanban board, and the whole team is sitting around a table talking about sports. I coach them through the 25-minute Scrum meeting and then, the next day, there are no chairs in the conference room when the team arrives. Of course, the team thinks this is really funny.

They also realize that we are going to stick to even the most basic principles of Scrum. When we begin placing stories (we had already planned by this time) on the Kanban board, I start to see the eyes of the team light up just a little. The first information radiator is in place. Shortly after, our Scrum meetings are hitting our 15-minute target and the team is focused on collaboration and transparent communications.

Growth
Time passed, and during one of the Scrum meetings I noticed that a couple of the team members had fallen back into providing status updates to me, instead of sharing knowledge. One team member in particular was very young and very smart. When he began providing his update, I turned to face the wall and didn't look at him until I heard him stop speaking. When I turned back around, he had a confused look on his face. I asked, "What just happened?" and several of the team members reinforced the principle of communicating with the team during the daily Scrums and not providing status updates (pizza party!!!). This helped me understand that the ScrumMaster can be an information radiator by simply using body language to help the team remain focused.

Later that week we experienced some issues and I went to several of the team members' desks to discuss our course of action. To my surprise, they had built personal Kanban boards at their desks to track their tasks at their level. Yah! Success!

Senior leadership growth
Once we were in a full swing of sprints, I started placing product burn-down and sprint burn-down charts beside the Kanban board. This required a little bit of training with the team and product owner, but they started seeing the bigger picture. The team really enjoyed seeing the burn-down charts progress, and it built a feeling of accomplishment. Then the competition started. How many tasks can we move from "In Progress" to "In Testing," and how many tasks will the tester move back to "In Progress"? The team was having fun, getting the job done, and producing a quality product.

After one of our daily Scrums, the product owner requested that I meet with the other stakeholders to discuss the project. During that meeting, the product owner told the other stakeholders, "You must see these burn-down charts. They tell us all of the information we have been trying to find for months." Shortly after that I was posting the burn-down charts (built in Excel) on an enterprise project status site for all of the stakeholders to see. While this was more work for me, it created a transparent communications platform that demonstrated to the entire organization the challenges of the project and the successes of the team.

Conclusion
Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results. -- Andrew Carnegie

"Information radiators" can be the fuel your team needs to be successful. Remember, we are Agile, so try new things that will work for the team and demonstrate the principles of Scrum. Use what works, tweak what needs to be tweaked, and get rid of anything standing in the way of team organization and transparent communications.

SCRUM + CMMI = SCRUMMI?

SCRUM and CMMI are often viewed in the industry as not being compatible.  This presentation was provided at the Cincinnati Day of Agile 2012 and demonstrates the tools and techniques already in place in many SCRUM teams that meet CMMI goals and practices. The bottom line is, if you are doing SCRUM you are already producing artifacts that CMMI will recognize.  Your already doing this stuff!  As promised here is a link to the article I referenced during the session.

SCRUM and CMMI, Why not embrace both.

SCRUM + CMMI = SCRUMMI?

View more presentations from mharbolt.

Thanks
Martin L. Harbolt, PMP, CSM, ITIL

Code PaLOUsa Success!

The Cincinnati Day of Agile event was a huge success.  The Coordinators did an excellent job.  My sessions on agile leadership  and Agile vs. CMMI were a lot of fun with very enthusiactic attendees. Thanks to all who attended.  Lots of great discussion.  Here is the menu and associated slide deck for Agile Cafe. Enjoy!

Twitter: @ProfMartyScrum

LinkedIn: http://www.linkedin.com/in/martinlharboltpmp

Blog: http://askthescrummaster.blogspot.com/

Get The Rhythm Menu

View more documents from mharbolt.

Get The Rhythm - Agile Leadership

View more presentations from mharbolt.

Get The Rhythm Sneak Peak

Get The Rhythm, Sneak Peak Twitter: @ProfMartyScrum LinkedIn: http://www.linkedin.com/in/martinlharboltpmp Blog: http://askthescrummaster.blogspot.com/

Ever been to a restaurant?  Get Really Great Service?  Really Bad Service?  Come visit the Agile Café and learn how these life lessons can bring immediate value to your agile project team.  We will scrutinize the café menu, have some fun give a ways and learn interesting tricks to help your agile team become more self organizing and get into a successful rhythm.

What’s on the menu?

Appetizers	Entrees	Dessert	A la Carte
Preparing to Lead	Rhythmic Leadership	Leadership with Goodies	Leadership Principles
The Team	Product Planning	Kanban Board	Missing Roles
The Organization	Sprint Planning	Sprint Burn Down	Follow the Process
The Process	Stand Up	Product Burn Down	Negotiate Rhythm
	Sprint Review	Life Cycle	Identify Impediments
	Retrospectives		Build A Rhythm
	Building a Rhythm		Monitor

Visit Code PaLOUsa and Learn from great speakers, network with peers and have some fun.

Free PMP Exam Question

The following PMP® exam sample question is taken from the Free PMP Exam Simulator at http://free.pm-exam-simulator.com/ - The answer is at the very bottom:

------------------------------

What is risk tolerance?

A.) Risks created by tolerating customer behavior.
B.) Willingness to accept varying degrees of risk.
C.) Risks created by zero tolerance.
D.) Being tolerant if stakeholders are willing to accept risks.

------------------------------
Hint: Look for the “least strange” answer.
------------------------------

All our questions are updated to the latest PMBOK® Guide standard. Stop by at http://free.pm-exam-simulator.com/ and try the PMP Exam Simulator free for 3 days. We also offer 110 free questions at http://www.free-pm-exam-questions.com./ We are a PMI Registered Education Provider.

Until next time,
Cornelius Fichtner, PMP
President, OSP International LLC
The Project Management PrepCast™ - http://www.project-management-prepcast.com/
The Project Management Podcast™ - http://www.project-management-podcast.com/


ANSWER AND EXPLANATION:
The correct answer is B
Explanation: Do you feel that A, C and D are odd? Correct, they are and they were included intentionally. Sometimes you can expect to find some “funny” answer choices.
Risk tolerance is the stakeholders' willingness to accept varying degrees of risk. Choice B is the only correct answer to this question.
Reference: PMBOK4 - pg:276

Critical Path Mapping: A Basis for Agile Project Management

As certified project management professionals, we are intimately familiar with the processes necessary to define the critical path of a project.  How does that apply when managing an Agile project?  One of the best approaches I have seen is a two phased approach to critical path definition.  Phase 1 – Define the High Level Critical Path for the overall project.  Phase 2 – Define the critical paths within each sprint as you initiate each sprint.  This approach allows you to define the steps necessary to complete the overall project as well as have more control over each sprint by defining the critical path within each sprint.  Whether you define a single overall PERT chart for the project, or separate PERT charts for each sprint is your choice.  Let’s take a look at a simplistic example:

Project Goal:  To build an information management system that will allow the user to communicate with other users, schedule events, manage registration for events and post comments related to the events.

Overall Project Tasks: 

Task ID	Task Name
1	Construct Test Environment (Architecture)
2	Construct Production Environment (Architecture)
3	Construct Test Environment (Software)
3a	Construct Registration Module
3b	Construct Scheduling Module
3c	Construct Communications Module
3d	Test Registration Module
3e	Test Scheduling Module
3f	Test Communications Module
4	Migrate to Production
5	Announce Launch

Project PERT Network Chart: 

This network diagram demonstrates the project as 13 weeks in length. Tasks 2, 3 and 5 create the critical path.

Sprint 1 – PERT Network Chart:

This network diagram demonstrates this sprint as 4 weeks in length. Tasks 3b and 3e are the critical path.

Sprint 2 – PERT Network Chart:

This network diagram demonstrates this sprint as 4 weeks in length. Tasks 3a and 4 are the critical path.

This simple example helps demonstrate how the scrum master can define the critical path of the overall project as well as for each sprint.  By defining each sprints critical path, the scrum master can ensure that the appropriate resources are working each task.  Focusing on those critical path tasks allows the scrum master to prioritize impediment management, scope changes, issues and risks impacting critical path tasks on a sprint by sprint basis.

Conclusion:  If a project has many tasks with dependencies on other tasks, understanding the critical path affords the scrum master the ability to focus resources on those tasks that will impact the schedule this most and therefore improve each sprints success which leads to improved overall project success.

Free PMP Exam Sample Question

The following PMP® exam sample question is taken from http://www.free-pm-exam-questions.com - The answer is at the very bottom: 

PMBOK Section: Estimate Costs                              

Process Group:     Planning Process Group                                        

Question Type:     Calculation                                   

Knowledge Area: Cost Management                                    

Difficulty Level:   Easy                                                                                                         

Question: You are managing an amusement park development project. You have received the following estimates for site excavation and area development activity that is critical to the success of your project. The most likely estimate is $100,000, the optimistic estimate is $90,000, and the pessimistic estimate is $120,000. What is the expected activity cost?                                                                                                                      

                                                                                                                                   

            A. $101666                                                                                                         

            B. $100000                                                                                                         

            C. $120000                                                                                                         

            D. $90000                                                                                                           

                                                                                                                                   

Hint:    Use the PERT formula.   


Reference: PMBOK4 - pg:173

The Great Divide - Project Management vs. Systems Development

The Project Management Life Cycle addresses specific project related activities such as Project Initiation, Planning, Schedule and Scope Management, Risk/Issue/Change Management, etc…  This life cycle can be applied to several disparate project goals whether building a house or a software application.  The same principles and disciplines apply.

The System Development Life Cycle addresses specific product related activities such as discovery, analysis, architectural design, development, testing, etc….  This life cycle can be applied to several disparate product goals whether building a server farm or planning a new system. These same engineering type principles and disciplines apply.

The clear delineation of these life cycles becomes critical when an organization is thinking about maturity certifications such as CMMI. When considering maturity certification the organization is focusing on repeatability and continuous improvement in order to improve quality.   Providing the Project Management professionals within an enterprise the chance to focus on project activities, artifacts and project process improvement, you afford them the opportunity to develop processes and procedures that best provide the results for the project.  Alternatively, providing the engineering professionals within the enterprise the ability to focus on product development activities affords them the ability to refine engineering aspects for the product so they produce processes that support repeatability, process improvements and a higher quality product.

Additionally, this separation of duties provides increased ability for education, mentor-ship and personal growth.  In turn, resources can focus their talents, passions and ultimately their career on the path they desire to travel.  This leads to an increase in specialty and productivity the project team and enterprise will benefit from.

Here is an example of how you can demonstrate "The Great Divide".

The Great Divide - Project Management Life Cycle vs. Systems Development Life Cycle

The Importance of an Agile Team’s Rhythm

The Importance of an Agile Team’s Rhythm

Setting up a new agile team?  Where do you start?

Rhythm! 

When setting up a new agile team it is important to immediately get that team into a rhythm.  Begin with the daily stand up meetings.  Schedule these meetings for the same time and place everyday.  This will help form the team’s basis of rhythm.  Once this rhythm basis is set, extend that rhythm to other project related meetings.  Depending on your team’s release plan, schedule the sprint planning meetings and sprint review and retrospective meetings to occur on the same day and place on a regularly scheduled basis.  If you have other required organizational meetings, verify these are also rhythmic and remember to keep the team from getting bogged down in approvals.  Also, help the Product Owner to not get tied to organizational deadlines by scheduling releases around those from the start of the project.  This simple strategy will keep the team moving and focused on the overall goal of product delivery.  As the team matures, their velocity will increase and hopefully you will need to adjust the rhythm to keep up.

Below is a sample schedule that could be useful:

Meeting Name	Frequency	Time	Room	Next Occurrence
Stand Up	Daily	9:00-9:15	Room B	Tomorrow
Sprint Planning-Part A	Every 20 days	9:15-11:30	Room A	15-Mar-2010
Sprint Planning-Part B	Every 20 days	1:00-4:00	Room A	15-Mar-2010
Release Approval	Every 20 Days	10:00-11:00	Board Room	25-Mar-2010
Sprint Review and Retrospective	Every 20 Days	10:00-12:00	Room D	26-Mar-2010

Other areas of impact:  Maintaining this chart in the conference room where the daily stand up meetings will occur will keep the team focused on the next step and all team members will know what is next and when it will happen.  This will also help the Scrum Master in scheduling the conference rooms with recurring events and help the team’s stick-to-itiveness (Sticking to the schedule).

Remember:  In the event something disrupts the team’s defined rhythm, Stop, Reassess and Start Over.

Happy Scrumming…..

Methodology Selection: Project Management (Part 2)

Previously we discussed 5 questions to ask when determining if a project will be successful when using an agile project management methodology like SCRUM.  Here are some additional questions to ask.

6)    Project Scope and Requirements: How well defined are the requirements and scope of the project?

If the scope and high-level requirements of the project are extremely well defined, you may want to think about a waterfall methodology approach.  However, if these critical aspects of the project are not well defined, an agile project management approach will work well.  This is because an agile approach allows the team to develop small increments of work based on small batches of requirements that can be defined as the project life cycle progresses.  Additionally, the business analyst can be working of requirements for sprint # 2 while the developers are completing design and development tasks from sprint # 1.  This creates a rolling sprint approach that promotes team self-direction and quick releases of the product.

7)      Team Composition: Is the team demographics small and cross-functional?

The ideal agile project team consists of a small group of cross-functional members.  For an agile project team to be self directing and successful the team should be 8 to 15 members consisting of the product owner, scrum master, developers, business analysis and testers.  Other functional members may be necessary to maintain corporate certifications such as CMMI.  In this case a quality assurance team member would be responsible for verifying the processes are documented without disrupting the team doing the requirements management and development.

8)      System Integration:  Can the majority of development be completed on a single isolated system?

When determining if a project should use and agile approach, we should consider how the development of the system will impact or be impacted by other integrated systems.  If there are multiple systems that need to be integrated, the development process could be hampered by external teams and external requirements.  For and agile approach the majority of development needs to be conducted on a single isolated system.

9)      Continuous Integration:  Can the project support test-driven development?

Agile project develop small increments of work product and implement those work products rapidly.  This approach creates the need for a critical link between requirements, development and testing.  An agile team should be able to develop initial work packages and refine the product of the work packages based on the test results and changing requirements.  This is also why it is important to have a small cross functional team that is co-located or has the tools to act co-located.

10)    External Dependencies:  Does the project have dependencies on external vendors, project or teams?

The agile project management methodology does not support extensive integration with other systems, projects, vendors, etc. because of the rapid pace of development and testing.  Extensive integration or regression testing can also slow product delivery. So is a project is dependent on the results of an RFP or delivery of hardware or software contracts.  An agile approach may not be the most productive approach to take.

So there it is.  Ten things to consider when determining if an agile project management methodology will support of successful project and product.  Some organizations have created tools to assist the project management teams in determining which project management methodology to use for each project.  An agile approach is not always the best and is no silver bullet.  Each project should be reviewed individually to determine the best approach based on the product, the project team and management support.

In January I will be presenting “Project Angels” to the Kentuckiana Chapter of PMI. And in March I will be presenting “The Great Divide” at CodepaLOUsa.  Hope to see you there.

Methodology Selection: Project Management (Part 1)

As a project manager, have you ever had a project sponsor ask “Can we use an Agile approach, this product needs to be developed ASAP”?   If you’re not expecting this, or have not dealt with it before, this could be a very challenging question.  Here are some questions to ask.

1)     Product Delivery: Can this product be delivered in pieces?

One of the core principles of agile is the ability to define a development strategy that delivers small pieces of the overall puzzle through short time boxed development periods.  This affords frequent product reviews and changes.  Even though some aspect of the product may take months to develop, there needs to be a clear strategy for delivering incremental pieces that when the project is complete, delivers the desired product.  Note that this is not limited to building just the product; this includes developing support systems such and an IT Infrastructure or an engineering design structure.  Anything it takes to deliver the final product should be considered.

2)     Project Team: Is the project team co-located and are they dedicated to this project?

Agile project function in short time-boxed increments because the core team is together and available.  Having the entire team physically located in a WAR room is ideal.  This includes the product owner, scrum master, developers, business analysts, testers and so on.  Anyone who has a stake in the project should be available.  Some of these challenges can be addressed with technology like live ongoing chat sessions, but for the most part the team should be together.  Availability is another issue, if you believe a project team member or members may be pulled from the project from time to time to assist other project team or team members will be required to be away from the office for travel, you should consider alternate team members.

3)     Governance: Can issues be escalated and corrected quickly?

Consider if the leadership is structured in a manner that supports frequent reviews and escalation.   Change is inevitable. Issues are inevitable.  Executive management needs to be available to review the product and make recommendation for improvement.  If you believe this will not be the case, request a governance structure or the delegation of authority to a team member that can support an agile approach to managing project risks and schedules as well as product functionality and quality.

4)     Commitment: Are the stakeholders committed and available?

If the answer is no, consider an alternate strategy.  Otherwise you will find the project team members waiting on decisions or guidance for the product specification.  Stakeholders such as the product owner or steering committee need to be able to adjust the direction and focus of the team when they deem it necessary to control product quality and scheduling.

5)     Testing: Is automated testing an option?

Testing of the delivered product is key to a quality product that functions within specifications.  This is in direct support of the time-boxed development approach of the product.  An automated testing approach can bring great benefit to agile projects so if that is available or implement able, do it.  If automated testing is not an option, develop a test strategy that has the testers available and flexible enough to support the fast movement of the team.

Summary: Agile project success depends on an incremental delivery strategy, team member availability and commitment, and iterative testing.

In my next post, we will discuss 5 other areas of focus when considering an agile project management approach and how it can be supported. 

Agile Arguments and why they fail.

Most of us have been there once or twice.  Sitting in a conference room with 15-20 resources discussing why agile project management won’t work.  Some of the comments I have heard in the past are:

“Agile is just the latest gadget, It’s not real world.”

“Agile Project Management is for cowboy teams that just don’t want to be managed.”

Or my favorite….

“Agile won’t work here because we have to maintain our CMMI certification.”

These comments are exactly why some organizations need to embrace Agile Project Management.  Here are 3 reasons to put these SCRUMphobia’s behind you and lead the charge within your organization.

3 – In today’s “Real World” development teams are utilizing technology like never before. By utilizing social tools like chats, tweets, blogs and others, the development teams can be geographically diverse and still maintain a level of collocation that supports the agile process extremely well.  By providing these tools to your team, you are empowering them to work together more aggressively and therefore, more productively.

2 – The daily stand up meetings are specifically designed to increase team synergy.  Teams that work well together become more self-managed as the project progresses.  When I am in a stand up meeting, one of my favorite statements I hear is “I can help you with that.”  This is a key sign that the team is self managing.  In fact, some organizations rate their agile teams and SCRUM masters based on how well the team manages itself.  A strong self managed team is a sign of a quality CSM.

1 – Organizations that are current working toward CMMI certification or are currently re-certifying should be extremely happy about utilizing the Agile project management process.  There are plenty of articles being published that demonstrate how well Agile supports the CMMI practices with as little or less documentation than other project management methodologies.   I personally, really like the fact that teams can demonstrate delivered business value by tracking the story points as opposed to an Earned Value type of approach.  Additionally, the product and sprint backlogs cover many of the CMMI specific practices.  Follow the Agile principles, keep the documentation current and you will be fulfilling the CMMI practices at the same time.

In summary,

Agile project management is a culture changes for some teams.  Helping them realize the benefits will help them take a step toward Agile.  That said, I must note that not all projects and/or team should use the agile methodology.  Each project and team must be analyzed to determine if agile is a good fit for the team, customer, project and organization.  A well rounded organization will have a process to determine which project management methodology should be used based on specific criteria.

Happy Scrumming....