UnitOfWork

The last 15 months I have worked as project manager, system architect and competency trainer at Transsoft A/S.

When I was hired, my task was to implement transparent project management, which would allow the board to know what development was doing and how the project was progressing. I also had to implement practices, which would empower the team to deliver software of a verifiable quality level.

ERP software is supposed to last many years, often 10-15 years. This means, that it must be built to be maintainable, and it must have a very extensible and flexible application architecture, which allow for easy implementation of customer specific busines rules and views.

In order to deliver a system with the kind of progress transparency and quality of architecture demanded by the board, I had the following agenda:

• Raise the general team skill level by introducing a common understanding of application architecture (appropriate for our domain),
• by teaching software engineering practices and
• by implementing agile project management.

Concretely:

• Implement Scrum for project management
• Teach the patterns and concepts of Domain-Driven Design to ensure a common understanding of (a) fundamental application architecture
• Teach common software design patterns and principles (SOLID among others) - again to raise the design awareness of the team
• Teach and implement several XP practices among them Test-Driven Design (and the practice of mocking) and later Behavior-Driven Development with a focus on user stories and executable specifications in the form of acceptance criteria

All these elements are needed in some form or shape, to deliver the kind of software we write. But the test-suite, that is the result of test-first development, is to me, the most important element, to ensure a steady progress and a certain level of quality to the code. A Lot of Good Things emerge when you do Test-Driven Development/BDD that I will not reiterate here,

The last few months I have spent a lot of my time developing a course department in Transsoft. This has had the consequence, that I haven't had the same focus on our practices and quality of the code, that I had before. My lack of focus on our practices have resulted in a rotting test-suite.

After a major refactoring (that I gave the greenlights on), our tests were not kept in synch, and we could no longer rely on them. This has reduced the confidence of the team, as we can no longer run all our tests and know, that adding a new feature or removing a bug, has not changed the expected behavior of the system. In addition, the test-suite is now technical debt and does the exact opposite of its intention - it reduces confidence instead of reinforcing it.

We have changed our sprint plan to give the developers time to refactor the tests to get in synch with the codebase. We also did a brush up on our DONE DONE DONE definition as well on why we use the practices we do. But this work takes time, velocity is reduced and refactoring 500+ tests is a pain.

So my advice to any team practicing TDD or unit-testing is to NEVER, EVER ALLOW YOUR TESTS TO ROT!

Labels: Anti-pattern, BDD, Best practices, TDD

Four months ago I started a new job as project manager at TransSoft. In this post I look back on what I have worked on and what is to come.

Scrum
Since I started I have implemented Scrum as our main project management process. For us it is a great way to manage the development cyclus using frequent feedback from the customer. By the team's own estimate they are now more than two times as effetive as before Scrum. Personally I love that everything we work on, everything we do is visible on our Scrum board. I preach that if it is not on the board, it is not important enough to worry about. Lately I have plastered our walls with diagrams of our velocity, our burndown/release plan and the principles we work by. Again in an attempt to emphasize what is important to us.

Design principles
Every other thursday I teach the team a new principle. At the moment we are working through the SOLID principles by Uncle Bob. SOLID is five best-practice object-oriented design principles that you can apply to your design to accomplish various desirable goals like loose-coupling, higher maintainability, intuitive location of interesting code, etc. I think that the best I can offer the team is education so I'll be putting more energy into this effort in the future. The payoff is code of a much higher quality than before and the developers seem to enjoy the added power these new skills gives them.

Documentation
In the coming months I'll be working a lot on documentation. The solution we are working on demands different kinds of documentation. A user manual - a marketing manual - a technical manual for developers - a helpfile - an architecture manual and a few other types. Making these different manuals is not trivial and I need to brush up on how to write good documentation.

ITIL
A possible new area of work for me is Service Management. I am pushing the board to start implementing some of the practices from ITIL. In short ITIL is:

ITIL stands for Information Technology Infrastructure Library.

The Information Technology Infrastructure Library (ITIL) is a framework of best practice approaches intended to facilitate the delivery of high quality information technology (IT) services.

ITIL outlines an extensive set of management procedures that are intended to support businesses in achieving both high financial quality and value in IT operations.

These procedures are supplier-independent and have been developed to provide guidance across the breadth of IT infrastructure, development, and operations.

While I still love programming, I find that designing systems, teaching and management is much more challenging and I think that is the way I'll go in the future.

Labels: Best practices, ITIL, Scrum

So, yesterday I started on my new job at TransSoft A/S. In close collaboration with my new colleagues, my primary tasks are (in short):

• Implementing Scrum as our chosen project management process
• Implementing techniques, methods and practices from XP to compliment the Scrum process
• Defining and implementing the development environment
• Defining the base architecture of our systems

My secondary tasks are:

• Teaching agile principles and thinking
• Implementing learning and training as an explicit and prioritized practice
• Teaching and coaching in general
• System design and programming

The next few years we will be working on an enterprise resource planning system targeted at shipping agents (the ones on wheels).

Labels: Best practices, Development Environment, Job, Scrum

Image original source

Labels: Best practices