Showing posts from July, 2010

Agile/Scrum and Traditional PM-Risk

My history while using the scrum framework is that the framework is all about taking risks early and often in the development of the application. With every sprint iteration you are supposed to be building workable software for the business/stakeholder, so during every sprint you will un-covering risks and exposing shortfalls in the project. I think the key is that you are performing this function from the first iteration, not trying to gather all the risks you can document up front (waterfall) and waiting till the end so see if the application is a viable entity. I think that there are a few techniques from the traditional project management rule book that could work to your advantage while you implement the scrum framework. Here are some risk identification processes that you can employ at the beginning of the project, and as discussed before every undertaking of a sprint should uncover risks. Combining together the two frameworks (agile/scrum-traditional pm) processes should …

Agile/Scrum and Traditional PM-Quality

Quality in any methodology/framework I believe is the true measurement of a successful project. It's the project owner/business/stakeholders job to find out what his users expect and to document it in the product backlog. The success of your project depends on an early determination of the level of quality that the end user product must meet. Definition is no more important then who defines the level of quality, the end users should have final say toward defining quality in any framework. The business has an expectation that you will deliver the level of quality, and he/she should express that exactly the in details while prioritizing the product backlog. You MUST involve your project owner/business/stakeholders EARLY and often in the agile/scrum framework, he/she must be communicated with face to face when you reach the completion of each sprint, if you set up the team and expectations correctly from the beginning then the customer is always aware of it. There are a few qualit…

Agile/Scrum and Traditional PM-Scope/Change Control

Using the waterfall methodology all of the projects scope gets unidentified at the beginning of the project by using all the requirements gathered by the business/stakeholder. We (the business) wants to get every single requirement out, documented and up front because we know how much changes will cost the business using this type of project methodology, with everything defined up front=changes$$$$$. So the business/stakeholder asks for it all, anything and everything that they can think of and get in so they can cost it at the beginning of the project, again changes later on will cost them plenty.

Scrum loves change the teams embrace change, delivering working software with every iteration after every sprint keeps the costs down, keeps development working as a team, keeps software time-boxed for delivery cycles and documents good engineering practices thus saving time=$$$$$. With the business/project owner sitting in on all the meetings throughout the entire scrum, will result i…

Agile/Scrum and Traditional Waterfall-Quality Assurance

Quality Assurance-Waterfall
In traditional methodologies like waterfall, QA is primarily a function of the execution phase. If you ask the entire team if they know what is expected of them the answer would be “I don’t know that’s QA’s role” or you can try to convey to the team members that they are all part of QA and that they will have to work together to develop the end product to meet the standard of quality expected by the business/stakeholder. This is not a feature of the waterfall methodology that helps QA, putting QA in a specific silo and not throughout the development cycle is a recipe for disaster and unhappy stakeholders.

Quality Assurance-Agile/Scrum
In Agile/Scrum, the framework is designed to utilize the entire team in the testing of the application. When you set up teams you are assigning quality assurance team members with developers. They will bounce off each other the kinds of unit tests that will need to be run before each iteration, working as a team the develo…

Agile/Scrum PM and Traditional PM-Requirements

You have to start with a member of the business/stakeholder, someone who can make decisions NOT just a member of that business unit. You must make that individual a member of the scrum team, and there are only 3 roles on that team, product owner (business/stakeholder) team (developers, qa, etc) and the scrummaster. The business/stakeholder will create a backlog (requirements) of a list of features (product backlog) that he wants the application to have, he must also prioritize the list of features so the team knows what the most critical things for the development of the application are. The entire team will work together (unlike waterfall) to figure out how much work they must complete in each iteration. This is when the team will figure out how much work it will take to complete each feature for the application. I will talk about estimating in future posts, once the business/stakeholder agrees on the features for the application he/she must prioritize the features for the appli…

Work Breakdown Structure (WBS) Example


Agile/Scrum PM and Traditional PM

For the 3 years that I have worked in an agile/scrum environment, and after certification as a ScrumMaster I see little things that the traditional project management methodologies introduces into the agile/scrum environment. I think there are a few things that from the traditional side work well with agile/scrum, that does not mean falling right back into waterfall theories but there are a few things that I believe can be combined and are combined in the development arena. These of course are my opinions that I have acquired during my time working for a big (waterfall) organization and dot coms (agile/scrum). In my next few posts I will detail a few of the tools that I think can crossover from one framework to the other. Working for one of the biggest banks in the United States all the team members had their silo AND we were working on different floors. You never saw any of the stakeholders because they were on the upper floors and did not mingle with let’s say the "worker …

Scrum/Agile Projects-Lead Generation System-Team Development Model

So if you read Bruce Tuchman’s 1965 Forming Storming Norming Performing team-development model you start to understand that teams go through different cycles while building teams. As the team gathers experience it develops leaders emerge and relationships grow. The progression of the stages he describes looks like this (below)

1. Forming
2. Storming
3. Norming
4. Performing

Here are the features of each phase:

Forming-Stage 1-High dependence on leader for guidance and direction. As I described the ScrumMaster took charge immediately and started all the team members in a unified direction.
Storming-Stage 2
The team needs to be focused on its goals to avoid becoming distracted by relationships and emotional issues. Compromises may be required to enable progress. Leader coaches, which is why we were successful, LEADER COACHES! The first ScrumMaster on the project had the same qualities as a good teacher, coach, team player; he would listen, teach and unblock any impediments that were sta…

Scrum/Agile Projects-Lead Generation System-Good/Bad

The first project I used the Scrumframework for was a lead generation system for the IDG network, home of such publications as Computer World, InfoWorld, PC World just to name a few. The PM/ScrumMaster on this project had no PM experience and was the architect of the system, the system was totally new, built from the ground up.

1. He had NO experience-In this case it was a good thing, as a company we were able to convince the business/stakeholders that this was a faster to market framework and they gave us the green light. The leader was not familiar with Scrum and he applied just right kind of guidance as we built our teams. I think that he didn’t have any pre-conceived notions is what made the project a success, he was learning the framework with the entire team at the same time. I also believe his style even before implementing Scrum was a hands off style of management, not unengaged but was very keen on individuals showing what they could do on their own. I also believe that…

ScrumMaster Certification

So after working in an agile environment for 3 years I thought that I would become certified in this framework. I use the word framework or I believe that you can use the word methodology, if you look at the definitions they all seem to coexist together. I found the certification on the Scrum Alliance website and signed up for the course. The course was great; it made me think of all the things that went wrong on our first forays into this type of framework. The trainer Michael Vizdos was great; he broke up the class evenly between real world simulations and slide studies. He made sure that from the start he made the group feel like a team even though we were from different companies, countries, backgrounds, job titles and had varying types of skill sets. I am going to go over some of the things that I learned (next posts) so next time we as a team can improve on our projects, but isn’t that what Scrum is all about, learning as a team, learning together, growing together and bei…

Final Thoughts-Speed Indicators/Project Management

Now you have to tools needed to efficiently build a team and you know the approach to take from day one of your project. Using smart Project Management/Scrum-Master techniques at the inception of the project will yield results almost immediately and your team will also see evidence of your success. Remember you are part of the team you must use all of your organizational skills, people management skills and technical skills to get the project started and keep it moving forward. When you are diligent about keeping good records, tracking and updating your project documents your control over the project expands. Try to stay on your schedule, evaluate risks, and use your Work Breakdown Structure (WBS) to support your team and clarify the skills and skill sets needed to maintain your projects delivery date. We have used these tools on many projects most recently development of simple syndication sites (exp 1, 2, 3) I have also attached a slide-share presentation that crystallizes all of …

Speed Indicators-Project Management on Steroids (Development Starts Now)

Starting Development
Now your team can start the “real work” of the project, and now you are very dependent on your team leaders, teams and the business/stakeholders. You must have meetings at regular intervals, this is where Agile comes into play, the “daily stand-up” should follow these guidelines.

• Meetings start on time Always!
• Meetings last no longer then 15 minutes
• Same place, same time, same location All the time!

Three Questions should be answered by all Team Members during these meetings

1.What did you do yesterday?
2. What are your plans today?
3. Any issues that prevent you from accomplishing your goal?

It will be your role as the Project Manager or Scrum Master to facilitate resolutions for any impediments. Also do these OUTSIDE of this meeting (daily stand-up) so the stand-up can run the 15 minutes of allotted time you give it each day. Keep the team’s momentum up; Agile helps your cause because you are working in 2 or 4 week iteration cycles delivering working softwar…

Speed Indicators-Project Management on Steroids (Go, Go, Go)

Here you GO
Now all team members are up to speed and have a clear concept of the project and all the results of your planning sessions are known by the leaders/stakeholders/business. You know what the project end game is all about, and what the project will look like so HIT THE BUTTON AN GO! It’s time to create your “work breakdown structure” a WBS is a list of all the tasks that will be performed on the new project and are broken down to small units to help in the manageability of the work. I have worked on projects that had a WBS and ones that did not. The ones that did not, the project managers seemed to not have full control of the project, like a ship in the wind with no captain.

Take that Plan and EXECUTE
Start by assigning team leaders to help develop parts of the plan, these are the leaders you assigned as the leaders (earlier post) for your planning sessions. The only hand holding and coaching you should need to do is to give them YOUR expectations of their role. Make su…

Speed Indicators-Project Management on Steroids (Scope/Planning)

Scope the Project

So the business/stakeholder has defined the scope of the project, the scope of the project is the set of objectives for the project that will be undertaken. All of the business goals will be derived from the requirements put forth by the business, and the objectives are derived from the requirements. Goals of the business)-Requirements gathered from the business)-Objectives (of the project). That’s why the project was kicked off initially to meet the objectives of the business/stakeholders.
As the project plan comes together you are going to have to break down the scope of the project into smaller pieces all the way down to the individual task level. When you share the scope of the project completely with your team you will need to give them the full insight into the development the project. Bring everyone together to detail the scope from inception to completion and try to use some kind of media (power-point, visio, and white-boards) to convey the new applica…

Speed Indicators-Project Management on Steroids (Updating Plans)

Your new development project has many plans associated with it, risk plan, testing plan, communication, schedule etc. Maintaining, updating and maintenance of all your plans in a timely manner can become a full-time job if you are not on top of them. Failure to do this will probably result in a failed project and or sitting in front of the business/stakeholders for an audit to see what happened to the project. The two plans that I think you need to keep the closet track of during any application development project are the communication plan and procurement plan.
• Communication Plan
The communication plan will include all information on the business/stakeholders that you will need to communicate during the course of the project. You will need to know Who, Why and How to communicate to the business/stakeholders, this report as well as examples of reports and procedures associated with the project.
• Procurement Plan
You will need reliable numbers, emails, and contact names to all …

Speed Indicators-Project Management on Steroids (Quality Assurance Testing)

Risk Analysis, Risk Management, Risk Mitigation, and Testing, as you work through your schedules and costs the risks you discover will become more pronounced.

• Speed Indicators One-Quality Assurance (testing)

In all my years working on multiple kinds of technology projects, testing I still believe is overlooked. Time is always allotted for the testing of the product BUT I have never seen a testing time-line that was not compacted because of schedule/cost overruns. Old school methodologies always preached that ONCE the project was completed then testing could commence. With the implementation of the Agile methodology each iteration (2 weeks) involves requirements analysis, design, coding, unit testing, and acceptance testing. You must “plan to test and to test early and very often”, these are basic traits of the Agile methodology “conduct your tests throughout construction of the application” The team knows the requirements, the developers can work in unison with the quality ass…

Speed Indicators-Project Management on Steroids (Schedules/Costs)

Relationships of these two elements is extremely simple, “the shorter the time-line the less in development dollars, plain and simple”. You must think through all your decisions because any decision has cost ramifications toward the project. Length to the time-line as well as costs can add up quickly so you see the direct correlation of schedules/costs.

• Speed Indicator One-Tech Events related to Schedule/Cost
Tech events (technology event) seem to crop up in all projects; they usually have to do with tools, hardware or software issues. They are VERY hard to predict, there unpredictability/frequency in all projects can put a damper on both Costs and Schedule creating a runaway project. You must look out early in a project, maintain constant risk planning and be alert throughout the project life-cycle.

• Speed Indicator Two- Quality Review related to Schedule/Cost
As you focus on the development schedule/costs factors, you will have to start the discussions on quality assurance.…

Speed Indicators-Project Management on Steroids (Supervision)

Indicator Number Two-Team Supervision
Teams come in all shapes and sizes as do the individuals who work on them, one type of supervision for all members of the team will not work. As a Scrum-Master you will have to decide who requires one on one supervision, occasional supervision, and who is self-directed. Self directed team members usual provide the increased speed to the project. My experience is that the occasional supervised team members are usually the largest group involved in the team. I believe that they are the engine that drives the team and by applying the right amount of supervisors and support they will become invaluable to the team. Try asking the team members to self evaluate their skill sets, the earlier in the project that you discover this, the better you can make the “Supervision” speed indicator work.

Speed Indicators-Project Management on Steroids (Team Speed)

Indicator Number One-Your Teams Speed
As a Scrum-Master you must know what skills are going to make your application development project a success. At this point you will need to evaluate your skill sets amongst your assembled team. You can assign skill levels to team members (from novice/intermediate/expert) and try do to this at a rapid pace, now if you are brought in to a project that is “in the weeds” it will become more complex because of time constraints involved with getting up to speed and not derailing the projects trajectory. If you don’t have the time try to meet with the HR person to gain information on your team members skill sets, they might have insight from previous projects. When it is time to group your teams together to increase speed DON’T put a novice with an expert even if you think it will help in the novices training for future projects. Experts feel resentment and will usually slow the project down due to training the novice this is not a good idea. Exp…

High Speed Project Management or Agile, the Best of Both Worlds

In many of my previous IT roles Agile could not be implemented because of lack of expertise, resources or the buy in from management. Agile is pretty new and yes it is gaining acceptance I believe you can incorporate the old school (RUP, Waterfall) and the new school (Agile, XP). Buy in from management has always been (at least my experience) the hardest hurdle to overcome when trying to implement a new methodology for projects, so I am going to try to discuss (in the next few posts) combining the old and the new.

• Your Team: Priority Number One
Your team is your number one focus, without the team you don’t have a project. Without your team the schedule versus cost factor is just an exercise, you MUST have a team to schedule and a team to generate project costs. cannot neglect the importance of the schedule versus cost factor and the risk factor. All of these factors are interrelated. The moment your team is formed, it must be scheduled and it must have a budget (project cost). …