Introduction
As ever, this is a hastily put across compilation of the sessions that I attended on the two day Management agility conference held at the Sheraton Bangalore on Feb 27th and Feb 28th 2013. Everything in this compilation is lifted from http://agileindia.org/ai2013/index.html and copy rights belong to the original people who presented in the conference. The speakers I attended to are listed at the end of this note. Like everything in agile, this was a well attended, well done conference with no philosophers (excluding the likes of me) and only practitioners. In other words these came from people who have made the journey from Apprentice to Master. Any mistake in this should only be attributed to me. For any specific details regarding this, please feel free to write or talk to me and I shall be happy to share whatever I experienced.
People, People, People
The importance of people was re-emphasized in all talks. Simply put success of agile practices depends on people and collaboration between them. Good people make a 10X difference in quality, speed and every related aspect. The essence was captured in the following text.
Clearly the role of conventional manager is changing to more of a facilitator. Their primary responsibility can be summarized as
- Help the team deliver
- Stop external interruptions to the team
- Make them better people than what they were when they got into the project
Polyskilled
People should transition to be what can be termed as an oxymoron. They should be ‘Generalized specialists’ having both the breadth and the depth. This can be visualized as follows and possibly said as having the ‘T’ skill. This essentially means everyone in the team knows what it takes to get software deployed to field (from analysis to rollout)
To illustrate how a bid (real life example) was won using agile teams the following examples was shown. This is overhauling an insurance company
Competition
|
Company that won the bid
| |
Project Schedule
|
12 months
|
8 months
|
Project Price
|
2 M $
|
1.1 M$
|
$rate/person/hour
|
28
|
87
|
ROI (Return on Investment)
|
4%
|
94%
|
This is the kind of productivity improvements that a Polyskilled team can demonstrate.
Technology Radar
Technology organizations should have a Technology Advisory Board (TAB) that shall meet frequently. ThoughtWorks uses this effectively and have a weekly virtual meeting and two face to face meetings in a year. The output of the two face to face meetings is technology radar that they publish twice in a year and which portrays their view on technology and makes a case to adopt/hold/trial/assess. A sample of the recent radar can be seen from the following link.
Emphasis should be placed on creating personal technology radar once in a year as well which helps to manage the individual’s knowledge portfolio. Individual should have four quadrants as shown below and manage this on a yearly basis.
Techniques
|
Platforms
|
Tools
|
Languages
|
An organization quadrant shall possibly look like this and it would be a good idea to map if individual directions and company directions are in sync.
Techniques
|
Platforms
|
Tools and COTS (Commercial off the shelf software)
|
Languages
|
A good litmus test for choosing a particular technology can be as follows (Though it varies from organization to organization)
- Testability
- Integratibility
- Narrow suitability to task
- Adoption
The benefits of adopting technology radar for the organization and individual can be summarized as follows
- A platform of continuous analysis
- Unified message to non-technical but interested people
- Excuse to get together and have impassioned conversation
- Business view of technology
- IT view of technology
- Being Aware of the "Competitive blind side"
- Manage your knowledge portfolio
- Proactively guard your career
Engineering Fundas and Metrics
- Postpone important decisions to the last responsible moment. (The basis is that is extremely impossible to know everything upfront with changing times)
- Minimize constraints and maximize flexibility
- Architecture and Design are separate. Have very few ‘non-changeable’ elements in Architecture.
- Do not be bogged down by boat anchors. Just because a tool is bought do not use it or do not base your decisions based on that.
- Have a look at antipatterns catalog (http://c2.com/cgi/wiki?AntiPatternsCatalog) and take care to avoid the relevant pitfalls
- Hawthorne effect - Measuring and let it be known that you are measuring can improve productivity but there are side effects that can make this counter-productive.
- There is no one single metric that can make a difference but the following can act as information radiators and probes with respect to the quality of the code that we are building.
- Cyclomatic Complexity
- Afferent/Efferent Coupling
- Instability
- Jdepend (http://clarkware.com/software/JDepend.html) can give the above metrics and other metrics that are esoteric. But I feel the above will give a view of code and package quality and can be used as a start to stop ‘Bad Coding’
- Relative complexity of code can be measured from Source Monitor (http://www.campwoodsw.com/sourcemonitor.html)
- A kiviat chart visually displays a set of metrics that provides easy viewing of multiple metrics against minimum and maximum thresholds (http://devcodemetrics.sourceforge.net/Metrics.htm)
- Other tools that can help are
Inverting the testing pyramid
The two diagrams are self explanatory on how testing should be approached. This also provides a possible tool list on what tools could be used at what stages
Nice things re-produced
- Agile can scale from 2 member teams to 2000 member teams co-located or distributed
- Agile not only web applications. Have been proven in all kind and all scale of applications (From startups to giants like Ericsson, Intel)
- Agile architects are coding architects
- Safety isn't success
- Velocity isn't value
- Good process looks bad
- One balanced team not client -vendor
- Working as a team of co-makers requires mindset changes
- Reality bites
-
System 1 ThinkingSystem 2 ThinkingFastSlowReflexiveDeliberateResponsiveRationalExpertiseAnalysisIntuitionEvidence, plansTacit KnowledgeExplicit KnowledgeAuto pilotManual ModeOverrides System 2Checking on System 1Makes most decisionsBasically Lazy
- Getting better is a better option than being good.
- Worry about being resilient rather than perfection. If someone brings down Amazon can they recover in minutes or seconds? Though they design very carefully, they are not paranoid about ‘not going down’
- Focus on telling a compelling story
- Do not fall into the experience trap especially when in estimating
Move from- Productivity to impact
- Predictability to experimentation
- Efficiency to Decentralization
- Making money to making a difference
Deming’s 14 obligations of Management (http://www.managementwisdom.com/wedde14po.html). This was mapped to agile thinking- Create constancy of purpose to improve product, service, and people with the aim to become competitive, stay in business, and provide jobs.
- Adopt the new philosophy of continual improvement. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and become leaders.
- Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.
- End the practice of awarding business on the basis of price tag. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust. Minimize total cost.
- Improve constantly and forever the system of production and service to improve quality and productivity, and thus constantly decrease costs.
- Institute training on the job.
- Institute leadership
- Drive out fear, so that everyone may work effectively for the company. Fear paralyzes people and prevents improvement
- Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production as well as consumer difficulties. People need to understand how departments interact and affect each other.
- Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force. Only management can improve the system.
- Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
- Remove barriers that rob people in management and in engineering of their right to pride of workmanship
- Institute a vigorous program of education and self-improvement.
- Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job and management must create a vision and program to include and inspire every employee.
Conclusion
Speakers (Sessions I attended and the material came from)
- Craig Larman – http://www.craiglarman.com
- Naresh Jain - http://agilefaqs.com/nareshjain.html
