Best Practices When Moving To Agile Project Management
FeatherweightPresentationForDefense
1. FEATHERWEIGHT: A CHANGE
MANAGEMENT APPLICATION TO HELP
TEAMS INTEGRATE AGILE PROCESSES
INTO THEIR ORGANIZATIONS.
Chris Garrison
under the under the guidance of Dr. David Umphress
Auburn University
Department of Computer Science & Software Engineering
10/28/2009
3. Featherweight
Overview/Context:
Featherweight is an enhanced bug tracking tool that
provides support for key process principles.
It is an easy-to-integrate change management
application that helps teams incorporate agile
processes into their organization.
Featherweight serves as a process foundation upon
which teams that have little or no process maturity (ad
hoc) can mature their process as they are able.
4. Featherweight
The Problem:
Many software teams still use an ad hoc
approach to software development.
Evidence clearly shows that teams practicing a
process model outperform those who don’t.
5. Featherweight
Why aren’t more teams utilizing defined processes?
Expensive
Can be difficult to implement (requires training)
Roles/Constraints in model processes don’t always
match organization’s structure
Resistance to change
No knowledge of software process
Teams can get away with it – industry is immature
7. Featherweight
Personal experiences/Origins of project:
Our team starting using a bug tracking tool.
Estimates/sanity check (versus RHE)
Other benefits
Better managed requirements (versus emails,
meetings, in hall conversations)
Served as a “kiosk” for entire company: (sales,
marketing, support)
8. Featherweight
The Solution:
Build on the lessons learned with bug tracking
system
Expand bug tracking application and create an
easy to integrate change management system
that enables teams with little or no process to
begin practicing software engineering
principles.
10. Featherweight
How Featherweight supports process
integration:
Req. Management > Communication > Responsibility > Project Management
Featherweight is based on a bug tracking system
Provides forms to define features, bugs, etc. (“work item”)
Enables engineers to further define expectations for team
Designs (CRC Cards), test cases, attachments ( upload UML, screen mock-
ups, etc)
Workflow (Pier reviews, etc).
Tracks changes in requirements
Provides recursive capabilities for improved traceability
11. Featherweight
How Featherweight supports process
integration:
Req. Management > Communication > Responsibility > Project Management
Featherweight supports communication and collaboration
Web based application
Functions as an information kiosk
Promotes user collaboration by centralizing development assets in
one location.
12. Featherweight
How Featherweight supports process
integration:
Req. Management > Communication > Responsibility > Project Management
Featherweight enables teams to enforce Responsibility
Customizable workflow
Someone on the teams is always responsible for a work item until it
is resolved.
13. Featherweight
How Featherweight supports process
integration:
Req. Management > Communication > Responsibility > Project Management
Users provide estimates and ‘actuals’ for their work
Multiple estimates can be provided by a user
Designers, Testers, etc. can all provide estimates
14. Featherweight
How Featherweight supports process integration:
Req. Management > Communication > Responsibility > Project Management
Calculation/Ratio:
‘Actuals’ of completed items/estimates of completed items
Ratios for current release, last three releases, and last six releases
Example
User estimates 40 for a series of tasks
User actually completes work in 45 hours
1.125 ratio would be applied to remaining tasks for adjusted estimates
15. Featherweight
How Featherweight supports process integration:
Req. Management > Communication > Responsibility > Project Management
Review: By providing support for four basic aspects of software
engineering, teams can integrate some fundamental process
principles without large expenditures and organizational
change.
Teams gain:
Visibility into production
Means of repeating process
Ability to improve
17. Featherweight
Observations: Importance of communication in
agile process
5 of the 12 principles in the Agile Manifesto are
communications based.
Welcome changing requirements
Business people and developers must work together daily throughout the
project
The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation
The best architectures, requirements, and designs emerge from self-
organizing teams
At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly
18. Featherweight
Observations: Importance of communication in
agile process continued
XP: two of four guiding principles are collaboration
based
Feedback
Communication
XP: primary practices include
Pair programming
Collective code ownership
working with customers during project
20. Featherweight
Observations: Importance of communication in
agile process continued
A greater emphasis on communication and
collaboration is needed to match the
objectives found in agile model processes.
21. Featherweight
Observations: Tools
Tools abstract away detail to enable programmers to
focus more on translating designs and less time
dealing with configuration, boilerplate code and
other mundane tasks.
When a tool is adopted, teams create a dependency
on that tool.
Black box component
Loss of control?
22. Featherweight
Observations: Tools continued
Since tools are essentially abstractions, teams
need to be prepared to become experts in the
tools they use.
This expertise must serve as a substitute for the
ability to analyze and troubleshoot at a less
abstract/more detailed level.
23. Featherweight
Observations: Featherweight
Change management systems provide a starting point for teams to
integrate agile processes into their organizations.
Teams that utilize change management systems such as
Featherweight can incorporate agile principles without the expense,
training and time often required to implement a model process.
Requirements management, communication and collaboration, roles
and responsibilities and project management are all important process
principles that are at least partially supported by these systems
27. Featherweight
Observations: Lean Development continued
Detroit approach versus Toyota
Detroit
Minimize responsibility on worker (thought of as unskilled labor)
“All powerful engineer”
Toyota
Empower employee (thought of as skilled worker)
Shared responsibility
28. Featherweight
Observations: Lean Development continued
Parallels of some early/heavy plan-driven process
methodologies were based on the model of early
Detroit.
Lean practitioners would argue:
Plan driven methodologies minimize responsibility on programmers
Programmers: provided designs so specific, the code “falls out”
Rigid processes restrict good ideas coming from programmers
In lean model, teams try to push-down responsibility to programmers
programmers are highly skilled – they are NOT like assembly line workers in
Detroit.
The lean approach eliminates waste and maximize efficiency
29. Featherweight
Observations: Lean Development continued
There is no “The Process”
Lean process would probably not be appropriate very expensive,
high risk projects.
Lean development attempts to take advantage of the programmers
skill and experience to eliminate waste and be more efficient.
As the software industry matures, this will become more important.
Editor's Notes
Provide context for presentation:
Many teams still have few or no defined processes that they practice. The consensus is: teams using some sort of defined process outperform those that don’t.
Why still so much ad hoc?
Software development has been viewed primarily as an implementation activity – not as an engineering activity.
Process can be a tough sell:
Projects last 1 – 3 years
Programmers change jobs like they’re going out of style
Re-orgs
Understandably, organizations must question their ROI.
Release meetings were like negotiating for a car.
Slide read
These 4 key areas come from research and reading of :
Barry Boehm
Alistair Cockburn (pronounced Co-burn)
Jim Highsmith
Kent Beck
Also on books on XP, SCRUM, and Lean Development by Mary and Tom Poppendieck.
PSP played a large role as well
Transition : Let’s look at how Featherweight supports these 4 areas.
How do these 4 areas support process integration
Naturally good at requirements management. It is based on a R.M. tool
Provides forms to capture descriptions, attributes like priority, responsibility, etc. (fields based on Bugzilla, Bugzero and Jira)
Tracks changes – writes a record to the database when changes are made. Team members can add notes to the work item.
Define expectations: Include design, test cases, attachments
Recursive: Someone can create more specific work items under a parent work item when it needs to be split up.
Important if CEO enters an abstract feature – engineers can further define into requirements – improve traceability
All stakeholders can have access
It is an interface for communication by stakeholders.
Functions as a centralized repository for development assets.
Workflows vary from team to team. We’re all familiar with Requirements>Design>Implementation>V&V>Maintenance, but most teams true work flow doesn’t match this exactly. There is a lot of overlap in these phases. Featherweight enables teams to define their own flow. They can add pier reviews, requirement reviews, etc. Customizable work-flow coupled with the responsibility aspect of Featherweight puts teams in a good position to analyze and hone their processes.
For example:
If the quality of the software is not acceptable:
Are requirements detailed enough? Are the programmers solving the wrong problem?
Are the test cases or designs specific enough?
Is the work flow being followed?
Featherweight can help answer these questions.
Perhaps a “Requirements Review” is necessary to help ensure quality. The application can accommodate this.
This is how teams can improve existing processes.
Users can provide estimates for their efforts – as well as the actual time spent. This is used to create a ration of est/actual which better equips PMs to forecast dates.
Simple calculation:
actuals of completed items/Estimates of completed items/ = ratio
Ratio * remaining estimates = adjusted remaining effort
This is not as precise as say PSP however, Agile methodologies welcome changing requirements. The focus is not so much on schedules as it is working software. So this is an appropriate methodology for Agile.
Read slide
Changing requirements: communication
Business people and developers working together: communication & collaboration
Face to face: communication
Self organizing teams: communication and collaboration
Post/mortems/analysis: communication
Communication is a simple concept that is very hard to do well.
Software engineers are sometimes guilty of seeing software engineering as an implementation activity . We focus on the technical aspects and miss fundamentals of teamwork.
Tools are an indispensible part of software engineering. They abstract away a lot of the mundane detail. They can save a lot of time and effort.
But teams need to evaluate tools carefully, because they create a dependency on the tools they adopt.
Two of the “newer” tools I used were Hibernate and Dojo
Significant learning curve
Bugs
Workarounds
Had I been a guru I may not have run into the problems I did, but this begs the question:
Should programmers spend their effort learning specific tools?
Or should they focus on core governing principles and standards?
Technology evolves so quickly it is hard to justify spending a lot of time becoming an expert on a tool that may not even be supported in two or three years.
What happens when the next cutting edge relational mapping tool is released?
My estimates way off. I could have coded in sql in much less time.
Two Questions:
How do you blame your schedule overrun on a tool?
How do you tell your client that someone else’s software is causing a problem in the software they are purchasing from you?
Teams need to be prepared to be experts in the tools they adopt. A haphazard approach in tool use exposes the organization to serious risk.
Change management systems enable the integration of process principles into their organization.
Is Featherweight a process?
But is managing requirements in a way that enables teams to better communicate, collaborate and define expectations?
Is this repeatable?
Does it provide visibility into production?
Does it enable teams to continually improve on their process?
After WWII, Japan didn’t have the resources for manufacturing cars on the same level as Detroit (as Detroit manufactured cars).
Expensive single use machines
Engineers
Land
capital
Toyota had to “push down” responsibilities to workers
Workers who had experience shaping fenders were encouraged to participate and make suggestions about process improvements
Found a way (through empowering workers) to utilize multi-use machines. (Metaphorically) They bent all fenders with 1 machine.
Toyota “invented” empower the worker idea. This was not from some grand vision of “valuing your workers.” It was out of necessity.
Detroit
The old assembly line relied on “all powerful” engineers who controlled virtually every aspect of car production.
The workers on the assembly line were unskilled (and were treated as such).
Engineers designed the components, designed the worker’s tasks, and then timed them with a stopwatch for productivity measurements.
Responsibilities on the worker were minimized. Essentially eliminated.
Toyota
Flatter organizations
Workers encouraged to make suggestions and take on responsibilities.
They pushed down decision making to lower levels RAISING the level of responsibility of their workers. They were thought of as skilled labor.
Poppendieck would argue that there is a real mis-match in the heavyweight processes and the worker’s skills which is essentially waste.
Lean not appropriate for projects that have
High criticality (risk in loss of life & $)
Inexperience developers (unskilled workers)
Very large teams
