Just recently, my engagement to my project since Nov of last year has ramped down. So the past couple of weeks has been a time of transition for me into my upcoming project and also from me to the new PO of my previous project. This allowed an opportunity for retrospection, and also a chance to pick up on new stuff.
While looking up the available knowledge sharing platforms within the company, I came across the option to host stuff in our enterprise GitHub instance. One link led to another, and I came across…
- MkDocs – This is for project documentation; it allows the use of Markdown for writing content, and then you generate static site contents from that.
- Documentation as Code (docs-as-code) – While I’m not a programmer, getting familiar with the concept wouldn’t hurt. And as I read more, it’s not really exclusive to programmers.
- Diagrams as Code with Mermaid – Part of the family of stuff-as-code, this doesn’t trail far behind. I think what I find promising about this (apart from being free) is that this is going make comparison of versions easier since you’re comparing text files.
As mentioned, I did some retrospection. I collated some of my personal lessons learned and posted it in our project’s Confluence page. I also revisited Software Development’s Classic Mistakes. I tried rereading The Scrum Guide and some stuff on anti-patterns to see where we’re somewhat deviating (for guidance if it’s something we should continue or if we should “realign”). Then I tried to pull out project-agnostic stuff that could be helpful to me for starting a new Agile Scrum project and collated my notes.
With the notes in hand, I’m starting to use it as a reference for the new project, and I plan to just tweak accordingly as I find other useful stuff to add in. At this stage, there’s already a team working on the prototypes, and in theory, they’re prepping the solution or the design which will be handed over to the implementation team. So I’ll be keen on learning a lot more and looking for process improvements for the handover from Design Thinking to prototyping to implementation. Exciting stuff! 🙂
We had our regular team meeting yesterday and Dwight shared a couple of videos. They’re both from TED talks. The first video is a talk by Derek Sivers where he shows a dancing guy whose top looks like he’ll have a pretty mean sunburn right afterwards. He starts dancing like no one’s watching, first by himself. And then one other guy joins in, and soon there’s a big crowd dancing. The video and a transcript of the video is available here: http://sivers.org/ff. The key lesson I suppose is that although leadership is important, but being a courageous follower is also important.
The next video is by David Damberger, who is the founder of Engineers Without Borders. He discusses how projects that sought to help the needy — through building physical structures like schools, wells, and such — would often fail due to lack of maintenance. And then there would be similar projects also aiming to help the same cause but also ending up with the same problems. In the end, these projects don’t end up helping as much as they should have. Here’s a link to the TEDx vid: http://tedxtalks.ted.com/video/TEDxYYC-David-Damberger-Learnin. This reminds me of the value of lessons learned. And being in the software industry, it reminded me of the Classic Mistakes that I read about from Steve McConnell’s Rapid Development: Taming Wild Software Schedules. I previously blogged about it, so I got the notes from there and shared it to the team. In my post, I said that this list is not about rubbing salt to the would or adding insult to injury. It’s about knowing what most likely could go wrong (based on what had gone wrong a LOT), and taking measures to avoid them.
Last set of excerpts and notes on classic mistakes…
- silver-bullet syndrome – too much reliance on the advertised benefits of previously unused technologies and too little information about how well they would do in this particular development environment. when project teams latch onto a single new practice, new technology, or rigid process and expect it to solve their schedule problems, they are inevitably disappointed (Jones 1994).
- overestimated savings from new tools or methods – orgs seldom improve their productivity in giant leaps, no matter how many new tools or methods they adopt or how good they are. you are more likely to experience slow, steady improvement on the order of a few percent per project than you are to experience dramatic gains.
- switching tools in the middle of a project – learning curve, rework and inevitable mistakes made with a new tool usually cancel out any benefit when you’re in the middle of a project.
- lack of automated source-code control – exposes the project to needless risks e.g., problems with versioning, one dev overwriting someone’s updates, defects can’t easily be replicated since there’s no way to recreate the build they were using. on average, source code changes at a rate of about 10 percent per month, and manual source-code control can’t keep up (Jones 1994).
Third part of excerpts and my notes on classic mistakes from the book Rapid Development.
- requirements gold-plating – users tend to be less interested in complex features than marketing and development are, and complex features add disproportionately to a development schedule.
- feature creep – even if you’re successful at avoiding requirement gold-plating, the avg project experiences about a 25% change in requirements over its lifetime (Jones 1994). there’s no escape from changing requirements.
- developer gold-plating – devs are fascinated by new technology and are sometimes anxious to try out new features of their language or envt or to create their own implementation of a slick feature they saw in another product — whether or not it’s required in their product.
- push-me, pull-me negotiation – one bizarre negotiating ploy occurs when a manager approves a schedule slip on a project that’s progressing slower than expected and then adds completely new tasks after the schedule change. it’s like rubbing salt to a wound.
- research-oriented development – if your project strains the limits of computer science by requiring the creation of new algorithms or new computing practices, you’re not doing software development; you’re doing software research. software-development schedules are reasonably predictable; software research schedules are not even theoretically predictable.
More excerpts and notes on classic mistakes… this time on process-related ones…
- overly optimistic schedules – sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. puts excessive pressure on the team, which hurts long-term team morale and productivity.
- insufficient risk management – only one thing has to go wrong to change your project from a rapid-development project to a slow-development one.
- contractor failure – getting contractors is sometimes done to alleviate pressure off the team. but contractors frequently deliver work that’s late, unacceptably low quality, or that fails to meet specifications (Boehm 1989). risks such as unstable requirements or ill-defined interfaces can be magnified when you bring a contractor into the picture.
- insufficient planning – if you don’t plan to achieve rapid devt, you can’t expect to achieve it. it’s wishful thinking to think it will magically happen on its own.
- abandonment of planning under pressure – project teams make plans and then routinely abandon them when they run into schedule trouble (Humphrey 1989). the problem isn’t so much in abandoning the plan as in failing to create a substitute, and then falling into code-and-fix mode instead. after abandoning the plan, the work becomes uncoordinated and awkward. and it’s downright confusing when you’ve no idea on what’s happening and on who’s doing what.
- wasted time during the fuzzy front end – it’s not uncommon for a project to spend months or years in the fuzzy front end and then come out of the gates with an aggressive schedule. it’s much easier and cheaper and less risky to save a few weeks or months in the fuzzy front end than it is to compress a devt schedule by the same amount.
- shortchanged upstream activities – the results of this mistake — also known as “jumping into coding” — are all too predictable. rework! projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place (Pagan 1976; Boehm and Papaccio 1988)
- inadequate design – special case of the former; rush projects undermine design by not allocating enough time for it and creating a pressure cooker envt that makes thoughtful consideration of design alternatives difficult. the design emphasis is on expediency rather than quality. you end up with a design product which doesn’t actually help that much during implementation.
- shortchanged quality assurance – cut corners by eliminating design and code reviews, eliminating test planning and performing only perfunctory testing. result: product still too buggy to release. Shortcutting 1 day of QA activity early in the project is likely to cost you from 3 to 10 days of activity downstream (Jones 1994).
- insufficient management controls – few mgt controls to provide timely warnings of impending schedule slips; before you can keep a project on track, you have to be able to tell whether it’s on track in the first place.
- premature or overly frequent convergence – forcing convergence too early results to more effort as separate parts of the system aren’t ready and the people themselves aren’t prepared. extra convergence attempts don’t benefit the product; only prolongs the schedule.
- omitting necessary tasks from estimates – you still have to do these anyway. but without these considered into your estimates, you’ll look delayed or over budget.
- planning to catch up later – most likely, there is no later.
- code-like-hell programming – it is really just a cover for the old Code-and-Fix paradigm combined with an ambitious schedule, and that combination almost never works. it’s an example of two wrongs not making a right.
I first came across Steve McConnell’s Rapid Development when I found it on a colleague’s desk last year. Inside were several pseudo-bookmarks where people have left off reading and had probably forgotten to return. If I remember correctly, I myself have stuck in a calling card and some restaurant’s flyer. Anyway, my fave part of the book has got to be the bits on Classic Mistakes. They’re classic so, in one way or another, I had personally come across them in my own projects. As I went through the list, I could recall going “ooh” nearly cringing in recognition. But the reason for having this list is not to rub salt to the wound. Rather, this list highlights what you need to consider during project planning and risk management. It includes 36 classic mistakes categorized into 4 areas — People, Process, Product and Technology.
Here I list the people-related classic mistakes, together with some excerpts mixed in with a few notes:
- undermined motivation – study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor. some examples of stuff that undermines motivation include hokey pep talks, requiring overtime, management going on long vacations while team worked through holidays, providing end-of-project bonuses that didn’t compensate the overtime effort rendered.
- weak personnel – hiring from the bottom of the barrel can get project off to a quick start but doesn’t set it up for rapid completion.
- uncontrolled problem employees – failure to take action to deal with a problem employee is the most common complaint that team members have about their leaders (Larson and LaFasto 1989). seeing nothing being done about problematic team mates and suffering for their lapses can lower morale.
- heroics – emphasizing heroics in any form usually does more harm than good. an emphasis on heroics encourages extreme risk taking and discourages cooperation among the many stakeholders in the software development process. by elevating can-do attitudes above accurate-and-sometimes-gloomy status reporting, you miss out on taking the appropriate corrective action.
- adding people to a late project – most classic. think brooks’s law!
- noisy, crowded office – workers who occupy quiet, private offices tend to perform significantly better than workers who occupy noisy, crowded work bays or cubicles. a related link I tweeted before – http://tinyurl.com/7qyvta
- friction between developers and customers – customers may feel that devs are not cooperative; devs may feel that customers are unreasonable. effect of this friction is poor communication which leads to poorly understood requirements, poor ui design, and in worst case, customers’ refusal to accept the product.
- unrealistic expectations – inability to correct unrealistic expectation, overly optimistic schedule estimates. by themselves they do not lengthen the devt schedule. but there’s just trouble when unrealistic expectations in schedule or in features are compared with reality… it gives off the perception that it has gone too long or the features too insufficient.
- lack of effective project sponsorship – without an effective executive sponsor, other high-level personnel in your org can force you to accept unrealistic deadlines or make changes that undermine your project.
- lack of stakeholder buy-in – all major players in a sw devt effort must buy in to the project — executive sponsor, team leader, team members, marketing staff, end-users, customers. good buy-in leads to close cooperation and precise coordination of the rapid devt effort.
- lack of user input – projects without early end-user involvement risk misunderstanding the project’s requirements and are vulnerable to time-consuming feature creep later in the project.
- politics placed over substance
- wishful thinking – this isn’t just optimism. it’s closing your eyes and hoping something works when you have no reasonable basis for thinking it will. It undermines meaningful planning. causes trouble when reality blows up in your face.