In our previous post, Agile Manifesto revisited — Part 1, we discussed the obvious aspects of processes and tools as being necessary and desirable but only in so far as they exist to support the team members, facilitate interactions between them and don’t detract from the doing of the project as a result of non-intuitive interfaces, unnecessary complexity or other “anti-patterns” often experienced when using online project tools.
This is reinforced by the ideas in Principles behind the Agile Manifesto which include the principle that
Business people and developers must work together daily throughout the project.
When communication between project stakeholders is easy to achieve and contextually associated with the appropriate project, epic, work list or task being considered, then several of the agile principles are met such as providing the environment and support needed to get things done!
Teamfu facilitates this at a “detailed” level with task notes, task comments, and configurable notifications, and at a “oversight” level by pertinent project portfolio structure together with epics for pragmatic project road mapping.
Working software over comprehensive documentation is the second agile value. This esteems getting things done above describing what will be done, or what was already done. This of course is a perennial dichotomy for developers who are taught & expected to document as they work, all the while being rushed to deliver outcomes.
There is a plethora of development tooling that aids in the generation of documentation, and project tooling is not exempt from this expectation. The writing of well thought out & logically presented tasks (tickets) is one way in which the project manager can add value to the team — and means that developers don’t need to re-document requirements that are well enough documented by the capable scrum master/business analyst/tester.
Several other agile principles underpin this focus on getting to working software. For the purpose of this discussion we dwell just for a moment on
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Team exhaustion has been evident in many of the projects I have observed first hand.
The habit of attending mandatory project rituals become a good way to just get some extra billing by contractors whilst, like many religious activities, only being semi-present during the various repetitive & often unfulfilling meetings is hardly ever life changing!
In order for project cadence to be sustained, project rituals need to be short, to the point and focused on the developers & their development needs, and not focused on the scrum master or project management related activities.
We call blocks of work “sprints” but no-developer can continuously sprint. What we have experienced is that developers who get variety, with opportunity between sprints to explore and discover, in what we call “Ambles”, do not burn out.
Ambles, are also often used for design refinement and other necessary project activities. Maintaining release cadence is about having a development, release and refinement recipe for your team that works. For developers this may mean an amble now & then, and for the scrum master and project managers it often means adjusting their processes & tool usage to align to the rythem of the team.
The agile process, and project tooling work best, when these are invisible to the developers, designers, analysts and architects on the project. Then project administration just works without getting in the way of building working software!
Next: Agile Manifesto revisited — Part 3
