Methodology Wars Return of the Developer

1. Methodology Wars Return of the Developer Jim Walmsley Chief Architect, BIS2 bis2.net June 2010

2. A long, long time ago in a galaxy far, far away, it was two years into the DeathStar V2 project. The project had been falling increasingly behind schedule. Development iterations were lengthening and “refactoring” had become the major activity in the development team. The Project Manager Darth Vader visited to the site to inform the Development CommanderTiaan Jerjerrod that the issue needs to be rectified. Lord Vader arrives in time for the morning stand-up… Case I: The Project Menace

3. You may dispense with the pleasantriesCommander. I'm here to put you back on schedule!! Lord Vader, this is an unexpected pleasure. We are honoured by your presence. DeathStar V2 Project Morning Stand-up I assure you Lord Vader my developers are working as fast as they can! Perhaps I can find new ways to motivate them! I tell you this project will be completed as planned!

4. The emperor does not share your optimism. Case I continued He asks the impossible!I need more developers. Then perhaps you can tell him when he arrives. The Emperor is coming here???!!

5. That is correct. And he is most displeased with your lack of progress! Case I continued We shall double our efforts!! I hope so, Commander, for your sake. The Emperor is not as forgiving as I am.

6. Outline Software Development: a Craft What is this Thing Called Methodology? Case Studies Conclusion

7. Software Development: a Craft patterns • Not an art • Not a science architecture standards requirements experience deployment ctx ingenuity • A creative process • A collaborative process collaborate create • Aptitude and attitude • Years to learn • Mentoring

8. What is this Thing Called Methodology? • A Method: a series of steps taken to achieve some end. • A Methodology: • a description of a process • may be expanded to include the philosophical basis • the systematic study of how things are done Important words: process, discipline, philosophy

9. Philosophy Sometimes stated, sometimes not. Agile UP: • Your staff knows what they're doing • Simplicity • Agility • Focus on high-value activities • Each implementation will have underlying philosophies • Minimise risk? • Process can make up for variable ability among the staff? • Management must be in control? • Watch your back?

10. Methodology is necessary • Software development: • Numbers of people • Limited money • Limited time • Competition Industry-standard methodology: You don’t have to re-invent • Requirements, communication, reporting, change, risk, architecture • Budgets, stakeholders, responsibilities • Documentation • Transitions, sign-offs Methodology helps us manage the process of software development It is not the key to success. Here is an example…

11. Case II: Attack of the Programmers The Environment Largebanking customer Project to replace a key online application Overseas group companies looking for synergy Purchased an industry-specific framework Medium-sized team: Customer's BAs, Vendor's Dev & Test, several contractors The Methodology Modified RUP / Customer's

12. Case II: continued Observations Politics Team a bit dysfunctional Difficult to establish standards Toolset issues Project experienced delays: group companies requirements, framework, lab "specialists" Mongolian Hordes approach to resourcing The project was delivered but it was very protracted and expensive Dilbert Factor Lessons Methodology would have beenadequate for a smaller cohesive team. Politics can get in the way of making the right decision. Remember the Mythical Man Month. The team just was not happening. Imposing unpopular tools on the dev team as asking for trouble.

13. Yoda says… “A Developer must have the deepest commitment, the most serious mind.” "Remember, a Developer's strength flows from the Force. But beware. Anger, fear, aggression. The dark side are they. Once you start down the dark path, forever will it dominate your destiny."

14. Obi-wan says… “The Force is what gives a Developer his power. It's an energy field created by all living things. It surrounds us, penetrates us, and binds the galaxy together.”

15. Martin Fowler says… SEMAT (Software Engineering Method and Theory) is an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Its stated aim is to "refound software engineering based on a solid theory, proven principles and best practices“. …I got the distinct impression that the central thrust of the initiative is to create a software meta-method-kernel - essentially a set of common process elements for software developments that you can rigorously compose into a method for your own project. At this point I lost interest. …since people are the central element in software development, and people are inherently non-linear and unpredictable - such an effort is fundamentally doomed.

16. Lots of People say… It’s all about People, Processes and Tools! • Three things about Tools: • Awkward or unreliable tools will impede the project. It’s worth getting it right. • A common toolset helps collaboration. • Imposing unpopular tools on developers is asking for trouble. People: Are creative Are social Are political Are different Get sick Need respect Need rewards Don’t thrive on fear Need to have fun Have ambitions Have families Have issues Have rights Some are talented Some are not Some are reliable Some are not Some are right for your team Some are not

17. In Search of the Force • Methodology does not tell us how to write good software. • May recommend practices such as: • Continuous integration • Iterative development • Test-driven development • Prototyping Uber-methodologies are selectively used. May be only Reviews, Checklists, Document templates. May over-look the implementation phase. In the end someone has to write and test the code.

18. Case V: The Waterfall Strikes Back The Environment Large M&E Programme (up to 90 people) Key application for large customer in utilities sector 3GL Performance, availability and reliability very important Very short change window (about 1 hour per month) Customer relationship often confrontational Turbulent history at start-up The Methodology Waterfall Some flexibility: lightweight version for simple changes Monthly releases

19. Case V continued Observations Expert knowledge available from a strong group of senior APs and TAs Estimates fairly reliable A cross-section of senior- and intermediate-level personnel Informal mentoring Good team cohesion, trust within the team, low turnover Teams co-located Team leaders well in touch with the work Good reporting from developers to team leaders to PM Quality management Good process documentation and compliance (ISO9001 Certified) Process improvement programme Very few unscheduled outages Not much program documentation

20. Case V continued some more • Lessons • Appropriate methodology for the environment • The team rocked • good communication • good attitude to quality • a disciplined, capable team • Split a large team into smaller teams to get optimum size. • Colocate team • Seniors play important role

21. Case IV: A New Hope The Environment Medium web application development project Medium-sized customer, good relationship with the vendor Very budget-conscious Small team: Project Manager, Solution Architect, BA, two contract Java programmers (Sun Certified) The Methodology Modified RUP

22. Case IV continued Observations Toolset not quite adequate The project went through all the stages and sign-offs to UAT Performance problems noticed Independent review by senior developer Code so badly written that it could not be fixed Programmers did not produced what the architect specified –didn't know how No effective code inspectionor tech review

23. Case IV reloaded The Environment Medium web application development project rescue Medium-sized customer, damaged relationship with the vendor Very budget-conscious Small team: Lead Developer, 2 Seniors, 1 Intermediate, BA, Tester The Methodology Very lightweight Agile-ish Observations Minimal toolset Application redesigned and built using Struts Team worked closely, communicated effectively Application delivered, customer satisfied

24. Case VI: Return of the Developer The Environment Start-up company building a new BI product Entrepreneurial phase: dev team has to be responsive Tension between architecture and features Multinational Flat organisation – everyone knows everyone The Methodology Agile Short sprints, well-defined stories, iterative delivery Test-driven development Continuous Integration Sprint cycle: kick-off, estimate candidates, finalise sprint, develop, test, demo, sprint review Daily stand-ups: brief

25. Case VI continued Philosophy Trust Shared Responsibility Everyone can question Fun The Development Team Carefully selected Small, collocated, structured senior/intermediate/junior Clear distinction of roles: product owner, team leader, architect, senior product designer, senior developer Rocks Communication Carefully selected Small, collocated, structured senior/intermediate/junior Clear distinction of roles: product owner, team leader, architect, senior product designer, senior developer

26. Case VI continued some more Communication Wiki – all documentation. Skype & WebEx: conferencing, demos, phone Gmail, Google group services Big whiteboard No process document templates, no e-mailed Word docs Results Innovative new product to market in less than three years. Installed customers. Recognition in the industry.

27. Conclusion • Choice of methodology will be influenced by: • Commercial environment • Corporate standards • Customer standards • Experience with methodologies I believe that a simple methodology, well-understood by all and thoughtfully applied is a powerful tool. A complex methodology, not understood by all and only partially applied is a blunt instrument. And The Force? It really is about human interaction: teams that rock.