How to develop, manage and always stay focused

How to develop, manage and always stay focused


It often happens that managing stuff (Project Managers, Software Architects, Team Leaders etc.) have to develop software and manage projects same time. Everybody knows about deadlines, bugs fixes, rework, research, projects beginning etc. Those factors can easily make leaders go out of focus as soon as these factors are handled as new responsibilities. If you are out of focus the project managing becomes very complicated and projects progress can slow down multiply. Especially this can touch young specialists.
To avoid loosing the focus and keep “development process” at the most productive level you should always assign priorities to the tasks as soon as the tasks arrive and put that tasks into priority queue of your own tasks. Such priority queue should be composed right at the beginning. F.e. when you manage a project and develop a part of the same project by yourself you probably have a deadline and bug-fixing tasks that should be fixed by this deadline. If you fall deep in development forgetting to assign tasks to the other developers then you can loose control in managing of the project, this will slow the progress of development of the whole project. When next deadline will come closer the results will be disastrous because you as the most responsible unit become the weakest link hence you will pull down the team.
This phenomenon is nothing more than Eliyahu M. Goldratt’s critical chain that is excellently explained in his book named same. The difference is only that our critical chain lies on the plane of company stuff hierarchy, we can say on “vertical plane” when Eliyahu M. Goldratt describes critical chain that lies on “horizontal plane”, i.e. in the product manufacturing cycle.


“Horizontal plane” is concerned to the resources required to execute existing tasks of the project, when “vertical plane” is concerned to the resources of horizontal plane maintenance (supply taskflow for development and solve chain links problems). The critical chain in “vertical plane” can be named “critical chain of “higher taxonomy/system level”” because, again, it lies in the other plane and goes out of bounds of executive resourсes plane.



Considering this we have “planning resources plane” and “executive resources plane” in software development domain and almost everywhere else in development and manufacturing. This planes have own intersection points and form. The general plane that can draw the bounds of the general critical chain for the whole project.

If we will look at the general chain the main bottleneck is income of tasks, i.e. project management matter. Therefore when you develop and manage, then managing has the highest priority even when you have to program something urgently by the deadline. As I mentioned before you should always assign priorities for the tasks as soon as they income and put that tasks into priority queue where project management tasks must always be in the highest priority in your own tasks queue. And don’t forget to handle priority queues for every other executive resource.

Theory of Constraints in software development

Theory of Constraints in software development


In the first book about Theory of Constraints named “The goal: a process of ongoing improvement” the unit of manufacturing chain is a machine tool. In software development we should consider that chain links are people who are involved in development process, i.e:

  1. The client
  2. Product Owner
  3. Project Manager
  4. Designer
  5. Software developers
  6. Testers and QA people

As we know from the Theory of Constraints “the throughput of any system is determined by one constraint (bottleneck)”. For software development this means that very often the project depends on one person only. The throughput of the weakest chain link is equal to the throughput of the whole system, together any delay in sequential manufacturing is the delay for product delivery. Usually only development of different parts of the application, f.e. of mobile application can run in parallel:

  • Back-end
  • Front-end
  • Android application
  • iOS application

Anyway, running development in parallel does not mean that some parts of it are not dependent, i.e. client side is always dependent of server-side. You should always supervise the progress of back-end developer  because his work must be optimized for client developers. Developers should wait for back-end developer work done but they should not adapt to back-end developer work too much because such work style will bring the team to new bottlenecks. So the work of every developer in the team must be optimized. At ZeeSofts we perform such adaptation with:

  1. Best practices of development – if developer does not follow best practices – this means that he is the bottleneck.
  2. Technology – if we have a technology that is able to accelerate development  (improve the speed of development without loosing the quality or improve the quality without loosing the speed) but applying of such technology in a chain link depends on small changes of work of previous chain link ( f.e. back-end developer or designer) and he (previous chain link) does not adapt his work  – the previous chan link is the bottleneck.

There are other ways of optimization of development process exist. You should also consider that chain links should not pull the work from the previous chain links because the work of different chain links requires different skills. F.e. if a developer is fixing designs made by designer – you should know that you have a big problem in this bottleneck and this bottleneck consists of several constraints, not only one or two constraints:

  1. A designer was not in time with his work to satisfy developer – Сonstraint №1
  2. A developer does not do his work – Сonstraint №2 – the company looses profit
  3. A developer pulls designers work and do some design fixes – Сonstraint №3 developers will do design job slower several times
  4. A developer pulls designers work and do some design fixes again – Сonstraint №4 instead to hire one more designer a developer does other’s work – company looses money to pay to wrong worker

Together this constraints create tightly coupled bottleneck which should be optimized the fastest. Until you know how to dynamically optimize the bottlenecks your company will always be in the bush league.




Sequential project lifecycle is used in Waterfall methodology. The requirements are collected , then the design is approved, then back-end development starts and then client apps development start. Such projects last 3-5 times longer than Agile projects and clients do not like long terms. The Agile style can help us to reduce development time but not the costs because this style of development supposes to start work all chain links almost in parallel. It reduces long sequential project lifecycle to the series of short sequential lifecycles called “sprints” where small job of previous link is delivered to the next link in shorter time, f.e. one design screens it dispatched for development right after it has been completed. But such connections and work style can call to much more tightly coupled bottlenecks, so Agile style of project management requires much more attention to the bottleneck and team balance. Also the client should be responsible avoid delays with his feedbacks.




There is another situation which requires your attention. When a company has several projects on support phase or update phase of development – every developer is being assigned a task stack with tasks for several projects. Project Manager should be very skilful and know how to set priorities for every task to have all deliveries in time to satisfy clients.



It very easy to get confused with several projects when every developer is overloaded. To avoid this you should set tasks and projects priorities and then inline all tasks into the task flow with single line for every developer/team of developers/development unit.


Continuously optimized task flow in software development

Continuously optimized task flow in software development

or “Sprintless Flowing Priority Elastic Scrumban


Various methodologies of software development provide optimized project management for different cases of customer-contractor relationships and work styles. For any of those cases, especially when Agile methodologies are applied, optimization of the workflow in task queue is also very important.

According to the Theory of Constraints a task management in a task queue is the most important thing of work optimization. Unfortunately every of well-known project management methodologies overlooks work optimization in task flow since all of them are based on deliveries schedule.

In ZeeSofts we have experience of work in different conditions. Usually the requirements are completed less than 100%. Often in the middle of project lifecycle we have to add new features according to the client wishes. Taking this into account we have developed own suitable hybrid Project Management methodology. With the approach I will describe below we always are opened to new requirements and we are always both – flexible and optimized.

All you need to do is to consider any agile project in waterfall way, i.e. complete with requirements you are able to and start development phase. You also will need to use “Kanban system of manufacturing and supply management” but with small difference:
1) there is only one sequential task queue for every project component
2) any developer can take only one task at one time
3) tasks position is set up in the task queue according to their priority only:
a) the tasks whith depending tasks must have higher priority
b) as well as the tasks with other developers depending on have the highest priority
c) and finally the tasks with the near deliveries depending on have the most high priority.

Using Waterfall and Kanban this job becomes very easy todo. Since we talk about agile project, the problems happen when new requirements were approved:
– the part of done work requires modifications and all next tasks require modifications
– also there is new amount of tasks must be added to the general queue.

Agile methodologies provide the best solutions in comparison with the other methodologies for agile projects. Unfortunately those methodologies do not provide the best from the perspective of optimization because agile methodologies are supposed to complete the sprint before apply changes according to new requirements. Fixes always require more effort than development from nothing. So why to waste time to complete the sprint if it will be required to fix done work right after the sprint is ended? It is better to stop the sprint, apply changes and start new sprint. This approach is better, but if we will have small continuous incoming stream of new requirements then the Scrum Master will be bogged down with creating of hundreds of slightly modified sprints. The only one way to optimize this – is to combine Queue Theory with TOC and use plain sequential priority queue of tasks, which can be subdivided to smaller queues according to the tasks priorities and moved anytime anywhere just like railcars by locomotive. In terms of well-known methodologies this approach could be called something like “Sprintless Flowing Priority Elastic Scrumban”

Word “Elastic” here used because the next problem which is solved by TOC is “Critical chain elasticity management”. Originally TOC was applied to manufacturing and that’s why TOC mostly offers permanent bottleneck enhancement. In software development, using part time and contract workers we can make bottlenecks really elastic.

Reorganizing the task queue according to new requirements with help of TOC becomes really not a big problem and here is how to manage it:
1) complete current tasks by developers and stop the work
2) apply modifications to work done
3) change existing tasks in queue according to new requirements
4) set newly arrived tasks into the queue according priorities and dependencies (estimate how other tasks depend on newly arrived tasks and move tasks with lower priority to the end of the queue)
5) review priorities in tasks according to the next delivery, reorganize queue according to new priorities if necessary.

Queue confusion always take part after new tasks added into the queue. This cycle will help to avoid tasks line confusion by aligning task queue according to priorities and dependencies. This cycle should be repeated every time after a set of new requirements has arrived.

And finally

If you know how to optimize continuously the task queues for every developer then you can start analysis of high-level optimization i.e. optimization of project life-cycle workflow or low-level optimization i.e. optimization of business processes of development via different development methodologies like TDD, FDD, BDD etc. But every optimization must be integrated with respect to TOC rules and principles.




TOC Books in order:
The goal: a process of ongoing improvement
Critical chain
Necessary but not sufficient


TOC in software development: Agile and the Theory of Constraints