Learning More about Project Management

by anton 7. October 2011 15:49

After listening to the interesting interview from Mark Phillips by Tim Keirnan, I wanted to jot down a few points which I think are important to us as teamaton.

  • Project managers are not only there to distribute tasks. They should understand the customer and his or her needs. Afterwards he has to define goals for the project, and translate these goals for the different groups involved in the project (designer, developer, tester). Only after that has happened, can he transfer these goals into tasks.
  • Most of the difficulties (80%) occur because they are weaved into the project from the very beginning. There needs to be a clear vision (definition is crucial) – otherwise there will be friction and competing visions.
  • Work expands so as to fill the time available for its completion. That rarely happens in our team. Our difficulties arise from not making estimates and not having a fixed point for completion.
  • Multitasking is not a good idea. One should concentrate on one project, instead of trying to push two, three or even more forward. If you have more than one project to work on, try to separate them (don’t switch during a day or even a week).
  • Projects should be prioritized. So when time is getting scarce you know which projects can be halted to free capacities.

After that I looked at the Theory of Constraints and the five focusing steps:

  1. Identify the Constraint:  We are now working more with Kanban, and are sure to see at which stage work is piling up.
  2. Decide How to Exploit the Constraint: We try to distribute the work according to the load. We try to let the developers focus on programming, because they are usually the bottle neck, and give their other tasks to someone else.
  3. Subordinate Everything Else to the Above Decision: We can be more effective in this step by defining precise priorities.
  4. Elevate the Constraint: We are thinking, for instance, about hiring a student software developer.
  5. If the Constraint Has Been Broken, Go Back to Step  1: We haven’t reached that step, but will keep that in mind – trying to better the performance of our projects.



Agile – Last Man Standing

by anton 11. March 2011 11:51

We (teamaton) are beginning to develop a new web application, a ToDo-Management-Tool. It is our goal to be better at everything revolving around the process of developing this new application. Everyone at our company is diving into reading about and testing new tools and processes.

I took on the part of reading about different approaches to developing software, finding out about the pros and cons, figuring out which one probably suits best our needs, and gives us great power to develop the application effectively. I found the Wikipedia article on software development methodology, and went on from there to the different approaches.


Different Approaches



One approach is the Waterfall model, which is a sequential development approach with the following stages: requirement specification, design, implementation, integration, testing and debugging, installation, maintenance. This model assumes that all requirements are specified at the beginning. This is seldom the case.

There are many approaches which try to overcome the deficiencies of the Waterfall model. Seemingly all of them fall under the category of Software prototyping. Its main features are risk reduction, ease-of-change during the process, and involvement of the user.  For large projects some companies use Spiral model. Here the system requirements are defined in as much detail as possible to identify and resolve risks in the software development process. Our project is as yet not that large. Therefore we analyze risks only rudimentarily.

Rapid application development comprises many modern software development methodologies, like Agile software development, Lean software development and Scrum. The project is broken into smaller segments to reduce risk and provide more ease-of-change. Users are being actively involved in the process, and the software is build iteratively.


Iterative and Incremental Development Methodologies


Since requirements may change or the product owner may not now all requirements at the start iterative and incremental development methodologies are being used. The basic idea is to develop a system through repeated cycles of planning, design, implementation, testing and evaluation – and develop small portions of the software at a time.


One example is the Unified Process framework, which is iterative and incremental, use case driven, architecture centric and risk focused. Similar frameworks are the IBM Rational Unified Process and the Agile Unified Process.

Agile Development


Essentially we will use Agile software development. It allows for changing requirements, regular adaptation of the process, delivering working software frequently, getting feedback, and higher customer satisfaction. It promotes simplicity and trusting in motivated individuals involved in the process.


There is still much to learn about agile development. It is the superordinate concept for different software development methods like Scrum, Feature Driven Development, Extreme Programming. I will read about these in the near future. As a team we will need to adopt the mindset of agile development more thoroughly. The biggest mistake for teams using agile development seems to be to put implementation of the process over changing the way of thinking.


software development | methodology

About the author

Something about the author

Month List