The analysts and tools vendors have been talking about Application Lifecycle Management (ALM) for many years now and I think they have (of course) been somewhat self serving in their definitions. ALM seems to include whatever product category they have in the current price list and then promising their integrations’ would be managements answer to cost and governance issues. I hope to say more about integrations in the future, but I’d like to look at the scope of ALM for now.
If you ask vendors and consultants (including me) about ALM scope you’ll get answers such:
Requirements engineering
Software Configuration management
Dependency Tracking
Change control and work tracking
Test management
Software development tools and process
Software building and processes
Deployment
Process Governance
Depending on the vendor you might even get more traditional: Project and Program Management; Project and Application Portfolio Management/Analysis; and Service Management activities thrown in as well.
The usual sales pitch is that everything is managed via a common tooling and provides a common repository. The major, and often single, selling point of this approach is improved governance and business oversight of the SDLC.
However I think it’s useful and important to look at the definition of ALM from a customers perspective rather than as analysts or vendors.
It seems that a more pragmatic approach is to describe ALM as the methods, processes and tools that support the management of change for software systems — with particular, but not exclusive, emphasise on the SDLC. In this context it does not matter if we are using Agile or Waterfall approaches, we chose the best tools and processes for our particular situation. This of course implies that in eighteen months time we may need to re-tool.
Furthermore the methods tools and processes of project management (PM) are much more mature and there is no real need to include them in this evolving segment — they have their own. Obviously PM will have an influence and impact on ALM and we need to design our ALM approach to dovetail with it. I realise that most vendors will not agree with this.
I have come to the conclusion in order to ’sell’ ALM into the teams that will use it we need to ensure, front and centre, that ALM provides a ‘better/faster/more’ improvement in daily productivity. That should be the primary focus of what is delivered.
Governance, audit etc should be secondary attributes and natural site affects of using ALM (important though they are of course and usually the primary sales message).
So at a practical level we need to be able to provide teams and their specialists with the best tools they need to do their job. Additionally we need to provide a supporting layer of data flows, events and data repositories to
Assist teams with traceability
Provide the tracking and management visibility to effectively steer the ship
So the point of this post is to plead with vendors to stop selling a one size fits all tool suite with deep integrations and start enabling shallow API and effective integrations to allow a truly best of breed approach for customers software purchases. It’s a shame that ALF project is shuting down.
SD is a peer to peer bug tracker which can sync to itself, RT or Hiveminder. You can extend SD to sync to other bug tracking tools by writing simple adaptors. If you’d like to help make SD work better with your bug tracker, drop us a line.
With all the cool kids (and me) moving to distributed version control tools it’s been obvious that that there is a gap because our bug databases are centralised. Why is that a problem? Because code changes should always be booked against either a user story or a bug report. The link needs to be hard! i.e. I should be at least warned when I commit code without a ticket and when I look at a completed ticket I should be able to find the corresponding code. When you are committing code changes at 11,000 meters above sea level that can be a bit hard.
The only thing I know about SD is what I’ve read above, but already I want it!
[update 25/July -- the SD website now works so go for it!]
Many Dimensions consultants, trainers and administrators have their own personal recipe on setting up a standalone Dimensions CM environment. Here is my latest: Read the rest of this entry »
Document the process in some fashion. A process that is not documented can be very hard to talk about, agree and improve.
Following on from a brief twitter conversation with Kate this morning here is a simplistic example of how I currently document processes. The motivation for this approach is:
Simple to edit and and maintain
I hope simple to read and understand (even if you are not technical)
Can be used as the basis for detailed work instructions
A company I know has released a promotional video on YouTube to explain their solution space. Whilst I applaud their initiative, I can’t help feeling they look like a bunch of sad 40 year olds trying to do the twist at an Eminem concert.
Sorry guys, a 10 for effort, but minus several million points for style
The article explains it well and I have to say that it would make a very effective first test for team and process maturity. Try and see how well your team does…
Tool vendors love to talk about ‘Enterprise Change Control’ but what does that mean? Here are some attributes that I think define this label. Obviously there is further detail to be inserted behind each point (but hopefully all that will be revealed at OSDC)
Captures everything
E.g. bugs, questions, initiatives, enhancements,…
Does not drop anything
Does things the same (best) way every time
Records risks and progress
Authorises the risks and work
Keeps historical information
Is regularly reviewed for improvement
Is appropriate for the task at hand
Supports a clear “line of sight” from request to implementation
Using a ticket management and capturing all issues, not matter where in our lifecycle they occur
Not all software teams have tools that allow metrics to be gathered. Without metrics we cannot answer questions about productivity, process improvement or estimating other than by (hopefully) intelligent guesswork.
How might we address that in the short term?
Introduce a time sheet system: That’s complicated and requires tools to analyse the data
Ask people to fill on project work sheets i.e. a time sheet for a project, rather than for an individual. It should be filled as each project work product is delivered (e.g. domain model, fully dressed use cases, test cases, etc.). The sheets should be simple i.e. the deliverable, the project name, the project phase, dates and a summary total of effort and the number of people involved.
Armed with this simple information it should be possible to start gathering some more intelligent insights into how well the software process is working.
The Open Source Developers Conference 2007 call for papers has gone out and I have just submitted my paper proposal. Now all I need to do it write the paper and set up the demo’s… (if I get accepted)
I found this site, which has AlecTheGeek linked in their blogroll — many thanks for that. The site is a set of personnel technical notes and seems to be focused on software building and deployment. There is a lot of basic information, but it needs expanding with more personnel experience I think — could have lots of potential.
speech Linus Torvalds gave some days ago at Google, basically talking about GIT and Source Control Management
Codice Software have a nice blog entry about Linus’ presentation on Source Control Management. He does a nice job of expounding on the value of distributed version control — worth watching. There is further analysis by Kyle Cordes
However one question that is not obvious with distributed SCM is how to link commits to issues in the bug database. Do we we need a replicated bug database? If we we record the commit in a central database then we have a problem because we may not have access to the corresponding code…
In the past when I’ve looked at Change Management issues I’ve tried to concentrate on lower level more practical topics. However recently I have the opportunity to think about change processes at the a higher level and of course that let me to want talk about it.
When looking at a change process it is tempting to see it as a single process, one size fits all, i.e all changes can be treated identically. However life is never that simple because changes have multiple facets. As well as identifying which change process needs to be followed, change dimensions provide information to assist us in prioritising work.
The most obvious difference, and the one that most people first come across, is the budget difference. Depending on who is paying for an change (IT or customers) has a direct bearing on the approval process. If the customer is paying (either directly or indirectly) then they, or their delegate such as the marketing department, must be involved in the financial approval to spend money. If it’s ‘free’ then the customer involvement may be limited to status updates.
A second dimension is size. The larger the size of the change the greater the process complexity and check points. How do we measure size? A variety of metrics need to be used, typically financial cost to implement, architectural impact on the software system, impact on other systems, how many project owners/stakeholders exist (this increases the issues involved in communication and resolving conflicting needs). This concept is reflected in the ITIL change process which recognises three levels of change impact and has different process flows accordingly.
A variation on the ‘financial cost to implement’ value is that different software systems may have different costs to deliver a similar level of business value. So a legacy application that contains a lot of cruft might cost $x to deliver y benefit, however in a different part of the business a different system might take a lot less than x dollars to deliver the same amount of value. So when comparing changes in a priority list, looking at a pure financial cost may not be enough.
The third Dimensions of change can be considered as political, i.e. who is sponsoring or controlling our changes? Often the executive team are able to generate a significant amount of strategic work which could absorb the all potential development and related resources. However an organisation also needs to exist on a daily tactical level and there are significant improvements to be made by implementing as many improvements to the current business as possible. However these changes often appear less significant to executive sponsors because of their more tactical nature despite their possibly huge business value.
When the various facets of a change are taken into account we can then make some decisions about the change e.g. Who will make the change, what level of process maturity will the change need to follow, which budget will pay for the change, who will be involved in acceptance testing, when will the change be released and so on.
Next time I will discuss some practical consequences of this and how to avoid some of the resulting pitfalls
When you start to think about a software project one of the things you absolutely need to know is “Where are we now?” (along with “Where do we want to go?” and “How are we going to get there?”). This question is usually not thought about that hard, and if the team have been working together for some time they generally “just know” anyway. However for an ousider it’s an important question to think about. I generally look for the following:
What version control tools are in use and how is the information set up and used
Is there any documentation of process and
Does anyone follow the process documentation
How do the customers feel about the work the team does – how do they think the team should change (that can be a hard question to get honest answers for)
How are requests and issues documented (e.g. emails, post-it notes, bug tracking tool …) and how is the information used
What is the technology used (e.g. frameworks, languages, build tools, IDEs, deployment …)
What are the current ‘pain’ points (e.g. too much rework, too hard to understand code base, can’t refactor etc.)
How much budget and autonomy does the team have
This will help you build an informal map to assist in in planning any work and identifying issues that may need addressing outside of the current project work. The information should be maintained in some easy to understand form e.g. a Mindmap or WiKi and updated every month or two.
Fit is a tool for enhancing collaboration in software development.
I just bought Mugridge and Ward’s book on using the Framework for Integrated Tests. I have only got as far as Ch 4 but I am very excited about how this approach might:
Help my conversations with customers by encouraging the use of Fit documents and
Reducing development overhead by making it easier to implement automated testing for business rules
I hope to get a chance to try this on some projects in the next 3-4 months so watch this space.
If you noodle around the Internet you can find some very gloomy reports showing the number of software projects that fail to meet users expectations. Whilst many of the reports are paid for by vendors of Requirement Management software, they are still pretty depressing. Why are we so bad at delivering software to our customers? There are many reasons and volumes have been written about it, however I think we can distil it down to three main issues: Read the rest of this entry »
Regular readers will remember that a while back I wrote a few posts talking about the job of a ticket process to manage changes and issues; and more recently I have banging the drum about the wonders of Agile development. How can I reconcile what appear to be two conflicting approaches? Read the rest of this entry »
Is he saying a common source code control policy is a bad thing?
I say unequivocally that both source code control and change management are absolutely vital. However using an IDE over the top of these tools can be problematic for a variety of reasons:
How does one handle the sharing of code and modules between IDE projects when the common code is in the version repository. Unfortunately the answer depends on the combination of the IDE and Version control tool being used
How to handle re-factoring? (re-factoring is a good BTW) Again the final answer depends on the combination of your IDE and version control tool.
Is there an effective interface to your change management (ticket management) application/repository from your IDE?
Depending on the tools and technology used IDE integrations to Change Management and Version Control systems can be fragile. It’s an extra dependency to manage and support and not everyone wants to run a single solution from a single vendor.
use cases can be deployed with good effect when implementing an enterprise scale Application Lifecycle Management (ALM) system.
I found this article from a pointer the CM forum at the Xing networking site. Whilst I had considered the use of use cases before for process, I had not really thought about it a this level if granularity or the use of sequence diagrams to show higher level process. I might try some of this in my next Development Process engineering project.
Once obvious area of concern is that the products from such a UML effort will be too cumbersome to be useful and to hard to re-factor into more comprehensible documentation. Remember my mantra is “Appropriately Lightweight“
