T.A.M.E -Time-Ordered Agile Management and Efficiency

It was not just Tim Berners Lee who noted the responsibility of IT professionals - deep down, we all realize how important it is to understand the fallacies of our process - accept them and change them.

The following article is based on the premise that most of the agile practices tend to be so flexible, that they purposefully do-not bind you to follow atomicity as a practice. In particular, atomicity in time, or a unit of time, for implementation of the business case therein, tends to be presented in the form of various forms of estimation planning and sizing techniques like Planning Poker etc. For instance, nowhere does Scrum tell you to keep a backlog of only a said number of hours, and even though XP shows you proven methods of quickening delivery like pair programming and 40-hour work week and so many more – all of these do not converge in one place to bring a framework that is driven by the one most costly thing in delivery – TIME. What is the foundation of any implementation of a requirement?

Note: I was earlier about to call this ATOM. There is already such a principle, but followed differently.?

So, let’s talk about atomicity first.

Breaking it down to the smallest measurable unit will always help. Scrum, Lean, XP, Kanban – you can think of these as toolkits or hats that you don, for containers while you manage your projects. However, if you adopt any method you want, you can keep time measurement as the basis of your framework.

?

I seek to introduce the T.A.M.E - Time-Ordered Agile Management and Efficiency, a model designed to address the challenge of maintaining atomicity within agile practices, particularly emphasizing the importance of time management. TAME breaks down development tasks into 2-hour atomic units, promoting granularity and efficiency. Key artifacts, including the Atomic Timeboxing Unit, Atomicity Matrix, and Atomic Timeboxing Plan (ATP), aid in task management. Actors such as Business and Quality Analysts, Engineering Managers, and Developers collaborate to ensure project success. By combining agile flexibility with a focus on atomicity in time, T.A.M.E offers a practical approach to project management and delivery.

?

Artifacts:

?? Atomic Timeboxing Unit: All development tasks by engineers or the implementation team to be broken down to 2 hours each. Any task greater than 2 hours should be broken down to 2 hours. Anything that takes you lesser than two hours, should pass a quick sanity test by you before pushing it for quality assurance. Why two hours? Judge your team’s atomicity and allocation per project – more often than not, you’ll narrow down on this measure too.

?? Atomicity Matrix or the WBS: The traditional work breakdown structure developed for a project in agile, marks the smallest unit of tasks that need to be implemented. Here, the Work Breakdown structure needs to be presented in a way that

1. all tasks listed are of a 2-hour unit. ?
2. Every feature follows the standards of Behavior driven development, providing given, when, then statements.

?? Atomic Timeboxing Plan (ATP): The Atomic Timeboxing Plan (ATP) is a structured document or tool designed to assist teams in breaking down tasks into atomic units that can be completed within specified timeboxes. It is created daily by the Engineering manager and the implementation team. It provides a systematic approach for implementing the principle of timeboxing to enhance task granularity and ensure efficient work execution.

Components of the ATP:

1. Objective: Clearly state the project or sprint objectives and goals.
2. Timebox Durations: Define the specific time durations for each timebox. For example, you can have daily timeboxes of 2 hours each, leading to a workload of 6 hours per day.
3. Task List: a list of tasks or user stories to be worked on during each timebox. Ensure that each task is small enough to be completed within the allocated time.
4. Task Descriptions: A signature by all members of the team that all tasks are well understood by all everybody on the team.
5. Dependencies: Identify any task dependencies or prerequisites that may impact the order of execution.
6. Assigned Team Members: Assign team members responsible for completing each task.

?

Note: The atomic timeboxing plan needs to be updated daily, by the entire team, and the unfinished backlog needs to be accommodated in the next day’s plan.

?

Actors: So, who are the actors in such a framework? There can be a team structure such as:

?? Business and Quality Analysts – A project needs to be analyzed from the view point of a team of business analysts, for scope creep, quality, bugs and adherence to requirements. Their chief responsibilities are:

1. Coordinate with the client, and all external stakeholders to understand the business requirement. Coordinate with the engineering manager, to bridge the gap between the client and the team.
2. To create user stories according to the requirements presented by the client.
3. To provide acceptance criteria for each user story, as a collaborative function with the engineering manager.
4. Business research such as market research, target audience, competitor profiling, product strategy is to be done by the business analyst team.
5. To Test a deliverable for acceptability by the client.
6. The business and quality analysts will interact only with the client and engineering manager.

?

?? Engineering Manager – The engineering manager is chosen out of the tech team itself. The responsibilities should be well chosen along the lines of:

1. Engineering Research and design: All activities of research such as tech research, material in the case of construction projects etc. needs to be done by a person who is specialized in the implementation of the product, and has expertise enough on the implementation techniques involved.
2. To provide an input on the quality of user stories by industry standard principles such as INVEST etc.
3. Document solutions and Monitor Quality of Deliverable, from a technical standpoint and not a business standpoint.
4. Communicate with the implementation team, and log the progress of the user stories and tasks according to the work breakdown structure developed by the team.
5. Prepare project closure, and handover project technical documentation to internal stakeholders.
6. The engineering manager can interact with anyone on the stakeholder map as well as developers, business analysts, quality analysts. He is the key to understanding how far the project has progressed and if there are any hurdles in implementation.

?

?? Developers – The team that actually develops the atomicity matrix work breakdown structure and implements it. Their responsibilities are

1. They are to develop the Matrix keeping in mind that each task should be only of 2 hours, as decided in the Atomic Timeboxing Plan (ATP) and Atomic Timeboxing Unit artifacts.
2. They can not communicate with the quality analyst, with an intention to convince quality analysts about technical feature hurdles. Their flow of communication should ideally be through the engineering manager.

?

Benefits

?? This framework can easily borrow features from scrum, which do not cross the Scrum framework. For instance, since the roles are different in both, just borrow a sprint, and scrum events as part of T.A.M.E, keeping in mind the principle of atomicity, and the artifacts listed above.

?? The framework binds you to follow a unit of time, which Scrum, lean and XP don’t. That further implies that a team following T.A.M.E, will be on the same page regarding estimates.

?? The framework binds you to follow a flow of communication, rather than haphazard flow of communication throughout an engineering team.

Note: If you like my effort, do support by adding value to it, and testing it in your projects. Also, share the article if you think it helps.

?

?

?