Approaching projects - Part 8 - 2021-11-17
Do you have a project, a skill, a goal you'd like to complete or progress? Are you on your own, lacking leadership and structure, or could use more of it for yourself and your team? Here's what I've discovered works for me as a solo software developer and later as an engineering manager. This is a series of posts, the next post part 9 on wrapping up comes next.
In the last post Approaching projects - Part 7, I described how to organize, execute, and monitor the progress of a project's tasks. This post will focus on what to do while the project is being developed and implemented, how to cultivate and curate the plan and respond to changes.
Throughout this series of posts I will be using this user story: As a person with money, I want a custom computer desk to fit in a weird spot in my home. With the chosen solution: Build the desk myself.
Cultivating the plan
The difference between a project plan and manufacturing is that the project is being done for the first time, while manufacturing has been done already in controlled circumstances. A project plan will not go smoothly on all points, this reality has to be accepted. So while you may have written all the tasks and then delegated them to another human to execute and assemble, your job isn't done. Unless it is, officially. But be open to amendments and deviations. The next step is to proactively cultivate the project.
In my eyes, agile is about cultivating a project through its lifecycle.
So what is cultivating a project? Within agriculture it would be to raise a crop under controlled conditions to bear useful and bountiful product. Agriculture requires preparation of the land, seeding, regular follow up, and harvesting. There are several parallels to software development with this description. But what I'll focus on here is the regular follow up piece. Discovering and satisfying the needs of a project is intangible. And like any intangible deliverable, tests are necessary to ensure the deliverable will be satisfied. When a tangible test is not satisfactory, then an alteration to the plan is appropriate. Reacting and correcting the plan is essential to cultivating the project.
Reacting and Guiding
Delivering the right thing requires staying in touch with the needs of the stakeholder and sponsor, here by labeled the "customer". Often one of these two things happens:
- The customer's communicated expectations are not accurate and aligned with their needs for which the plan was designed for.
- The plan was not accurate in the approach to deliver what it was intended for.
This is the premise of agile, get stuff out so you can respond quickly. But before all the code and all the expensive effort... Keep in mind the user stories, the resources available to the end user, and take some time to "play house".
Upon discovering a discrepancy in expectations and reality, first start with the simplest least technically involved work-around possible. Think of it as a splint. It is something to get you by.
Sometimes the workarounds will cause more problems, you may have to answer to those as well once discovered. This is just the nature of constrained resources, limited ability to scope the impact of a decision, and what makes business sense at the time.
While figuring out and installing a workaround, I expect that you'll be exposed to the user story involved. Explore the problem space to find out what was meant to function in that space but did not, if something is lacking entirely, and so on. Iterate on the design, then realign the plan to the currently known reality. In a way, this first possibility (inaccurate expectations) leads to an inaccurate plan. The long term fixes to inaccurate expectations are the same tools as addressing an inaccurate plan.
Here's an example I had with my table. One of my early requirements was to have an insert to bring power to the desk surface with a circular extension interface. I chose one with USB ports too! Turns out these units have intense coil whine which I am sensitive to.
So now I have a battery backup on top of the desk and use the hole to pass the speaker cable through. I probably could send the power cables through there too but there is not a matching hole on the other side for routing back up. The wires will for now just pass between the back of the desk and the wall. This is a workaround with no priority to attend to.
When the project is not going as expected, you have a few tools to choose from.
- Design and redesign
- Splitting tasks
- Removing tasks
- Adding tasks
- Recurring Scheduled Reviews
When wholistic redesign feels necessary, consider that action fraught with risk and avoid.
When a partial redesign (or a patch) is necessary, do due diligence to measure the impact of the change and disclose this. If the impact is unknown, consider an experiment. Review the above tangent on explosive dust if you need justification on impact analysis with regards to changes. When making designs do review with the peers and maybe the stakeholder if appropriate. Include the findings on why the existing design did not meet expectations, the reality encountered, impact analysis, and the change proposed with sufficient justification and disclosure of resource expense to perform the change and long term resource commitments with the change applied.
Often enough, the optimal thing to do is unknown when expectations are not being met. Figuring out a known optimal thing may require experimentation. As a reminder, experiments should be agreed to by the sponsor. Experiments consume limited resources in addition the project execution. Further, experiments can harm reputation when communicated as a promise to solve something and the experiment did not provide a satisfactory finding. When a project is in motion, maybe even partially installed, an experiment may be to measure the effectiveness of a workaround. Additional experiments may be proposing and trialing other workarounds. At the end of a series of experiments, promoting the most optimal workaround with planned refinements may be the best move.
Regularly, tasks turn out to have a greater scope than the title and description suggests to satisfy its acceptance criteria. It is on the developer or implementor to escalate, they should escalate, but it happens enough that some proactive attention should be given specifically to identify tasks that should be split apart. Usually the solution is to take the acceptance criteria and piece it apart like a project.
Removing tasks that are no longer relevant is easy. It's like removing dead code. Yoink it's marked as "Done" ✅ "WON'T FIX" 🙅. Discuss it with the developer or implementor who would do it, then remove it from your tracking method of choice. Sometimes this comes up because the customer's needs changed, for example they upgraded something else early so a compensating or compatibility process is no longer needed on something. Other times its because the solution to a prior task already covered the functionality documented in the task under consideration. Lastly sometimes it's just a duplicate. No biggie.
Adding tasks is usually done due to new designs, missed details, tasks completed but not fully meeting acceptance criteria, or splitting up tasks. That or bugs were found. Maintain quality of task descriptions. You may need to come up with templates for on demand new tasks, such as bugs.
Lastly, recurring reviews. Some call this backlog refinement (formerly known as backlog grooming). The definition linked is exactly what I am thinking of. Get the team together to review progress made, collect outstanding ideas and concerns, alter existing tasks and delegate work. If this is a solo project, I still greatly recommend a time to step back and switch perspectives. What you discover and think about in your role as developer and implementor may have different meaning and be actionable at a higher level perspective. When the project is being actively deployed, stay in frequent touch with the end users or someone who acts as an interface between end users and the team making changes to process and resources. Signals from end users will affect priorities at this recurring event.
Wrapping up the install, roll out, deployment of a project comes next!
The main takeaways of this post are:
- The needs of a project becomes clearer the closer it is to being finished.
- The known needs are intangible and must be discovered through tangible steps.
- Inaccurate expectations by the customer often need workarounds and later improvements.
- Revising inaccurate expectations will result in an inaccurate plan.
- Inaccurate plans can be improved by redesign, experiments, adding / removing / splitting tasks, and recurring examination of the projects execution.
- Changes to designs, even if small, should come with impact analysis, and short + long term resource analysis
This post is the eighth of the series, part 9 on wrapping up comes next.