Monday’s Musings: A Year of Extremes Brings Us Back Full Circle to the Beginning of the Dot.Com Bust

With a few days left in the year, it’s hard to believe that 2008 is almost over.  Just like our paltry .401K’s and lowered gas prices, it’s like we reverted to the Dot Com bust.  Extreme contrasts in positions and tremendous change made 2008 both exciting. suspenseful, and frankly sobering like 2002.  In fact, it wasn’t just the pace of change, it was an intensity of change like no other.  For example in the topical areas I cover:

The Death of Process as a Product

During the last six weeks we have been researching the state of software development processes and a number of very interesting trends have become apparent. These trends and the results of our research will be documented in the research report Best Practices In Software Development Processes slated for Q1 2009. But I just couldn’t wait to share some of the insights and get your reactions to them before then.

Hybrid Processes take the floor

One interesting trend is the number of development leaders saying that they are not following Scrum or RUP, but instead talking about their process as a hybrid. Examples include Scrum and XP, RUP and Scrum and perhaps the most surprising DODAF and Scrum! Traditionally customization has always been a tricky job with organizations finding it hard to decide which process element to include and how these very different processes fit together. 

Process power to the people doing the work

So what has changed? Have organizations suddenly discovered the DNA of process and now can transplant X bit of one process to a Y bit of another process? Our research seems not to indicate that. Organizations are not trying to develop the perfect hybrid process, but instead leaving it to the development teams to select the bits that work for them from either experience or from the latest agile / lean method. Instead of focusing on building a perfect process and then getting all the teams to follow it, organizations are focusing on making teams more educated and process aware. The process police seem to be changing from enforcement to enablement. Here is my first pass at a three step guide to enabling practical process implementation;

• Empower teams to make process decisions – By giving teams the power to decide on the process they are going to follow, that process is much more likely to succeed.
• Educate teams on what they need to do to be compliant – Instead of hiding compliance behind a wall of process steps and artifacts, educate the team on what they need to do, when, to ensure that the project conforms to the company compliance steps.
• Enable teams to learn new processes and techniques – By encouraging a culture of continuous improvement teams are continually looking for new and improved ways to make do their work.

But with ownership comes risk

As with any change there comes a set of risks. By putting process power with the development teams mistakes may be made with time being wasted doing things that are not really valuable or activities being undertaken poorly. I encountered a number of war stories with customers starting a project and finding half way through that they really should have undertaken some work up front in the area of architecture or requirements and now are missing a key aspect of the system. In the case of these customers they highlighted two things for resolving these issues. Firstly having experienced people on the team. These may be outside consultants or internal experienced practitioners. The second tip was in the area of software development lifecycle with the implementation of a light SDLC, which describes a series of milestones and key events that must happen on all projects, but does not prescribe all the activities necessary to deliver those milestones. Another concern was highlighted by the management concerning productivity and efficiency of the teams. Allowing the team an almost free hand in the work they undertake could lead to very inefficient processes. You would have to address this with a set of measures being put in place that encourage efficiency whilst promoting ownership.

I would love to hear your feedback around the idea that the religion of process is going away and being replaced with empowered, educated and enabled teams who consider they can change the way they work. What are you finding?

Horses for courses?

I was on a conference call with my Research Director, Mike Gilpin and colleague Charles Brett the other day discussing complex event processing and business rules when suddenly Mike and Charles starting talking about "horses for courses". Say what? We went from talking about events and rules to horses and courses? I never heard this expression before so I asked. And, for those of you who think that I am provincial, I asked several other people in our Cambridge, Massachusetts office and they were dumbfounded as well.

Horses for courses means you have to choose the right horse for the right course. For example, if the race is a quarter mile you choose a quarter horse. If the race is a barrel race, then you choose a appaloosa. Choose a trotter for a harness race. And, a destrier for a joust. This horse information is courtesy, Jeffrey Hammond, a colleague who grew up in Kentucky.

You might be wondering what this has to do with application development? Simply this: One size doesn't fit all. And, in the future application development professionals will have more horses and more courses. So, we will have have more and tougher choices to make regarding the tools, technologies, architecture, and processes we use to develop applications.

I may never use the term "horses for courses" again, but at least I, and now you, know what it means.

Monday’s Musings: 2009 Enterprise Packaged Apps Predictions

So it’s that time of year for holiday cheer and pundits to tempt fate and pontificate.  I'm going to throw out some ideas that may make it in the next Forrester report.  So here are some very very draft predictions for 2009 in order of most likely to least likely to pan out:

End user predictions

1. Heavy discounting continues for new license. Discounts include non-monetary concessions such as training, implementation, integration, and other professional services.
2. SaaS contract terms move from annual terms back to month to month contracts.
3. Single source ERP strategies lose appeal as customers move to contain exposure to vendor lock-in with large ERP vendors.
4. SaaS integration becomes a requirement as customers seek hybrid deployment options.
5. Consortium and shared service buying move beyond the public sector.
6. Customers with more than 3 ERP systems move to reduce to 3 or less.
7. Custom dev shops extend functionality on PaaS offerings.
8. Software appliance adoption exceeds that of open source.
9. Lack of third party maintenance seen as anti-competitive.  Customers demand options.
10. Industry groups ban together to define web services and business process standards.
11. Open source SaaS software improves open source adoption rates.

Vendor predictions

1. SaaS vendors continue to take market share away from pure on-premise vendors.
2. Intense software discounting in Q4 2008 and Q1/Q2 2009 drives less capitalized vendors to go broke or be acquired.
3. ISV’s battle for ecosystem partners as capital for innovation becomes scarce.
4. Apps vendors torn between building on .NET, delivering their own SaaS offering,  or hosting with another vendor like SFDC.
5. M&A activity abounds in Gov Con (i.e. Public sector, Education, Utilities, and Defense verticals) as vendors seek to consolidate around public infrastructure spending.
6. Specialized apps vendors emerge to meet micro-industry niches and many arise from system integrators with software development expertise.
7. System integrators forgo vendor “warnings” and deliver on third party maintenance.
8. A few system integrators will acquire software vendors and drive towards solutions convergence.
9. Software vendors improve support and maintenance offerings.
10. Large ERP vendors cede the SMB market or acquire for market share presence.
11. Cloud computing remains a 2009 buzzword and every vendor will dilute the meaning till it becomes meaningless.

Your POV.

Send me your view of 2009 and what you think will be hot or not.  What’s the one trend you think will pan out?   Feel free to share with me your experience.  You can post here or send me a private email to rwang@forrester.com

Copyright © 2008 R Wang. All rights reserved.
Reposted from http://blog.softwareinsider.org

The Value of Projects – Do we always need them?

When I started in software development writing Cobol, sitting in an office with my humming green monitor. I was part of an IT department that was linked to a business department.  The work I did was in direct response to my customers requests for new features or changes to existing features.  We planned work at the start of the month and worked through that list during the month.  Yes, there were cross department projects, but that was handled by everyone involved sitting in a room and saying ‘if you do this, we can do that’.  It was a simpler time, a time when you could leave your screen unlocked and you had a real lunch hour. 

Ok – I am not just getting nostalgic for the sake of it, I honestly believe there is a need to re-evaluate the way in which we use projects as a mechanism for structuring and managing work and remind ourselves that there are different organizational approaches to developing software.  This realization came to me as I talked to a number of clients about the use of Agile approaches and Lean thinking in their development of software.  Many clients have run into problems when trying to implement one product backlog, stating that they need many project backlogs and then some mechanism to bring them together.  They need a backlog of backlogs (or a scrum of scrums J), and then numerous processes to manage the impact of change across those backlogs.  The process starts getting more and more complex and harder and harder to manage.  Can the application of project structures on work delivery be artificial? 

I consider four things when deciding if work should be grouped up and considered a project.

• Size of development team – When a team is large and work needs to be planned in a large amount of detail to take advantage of these resources then it is important to introduce a project structure and appropriate management and reporting to ensure this is working.
• Location of development team – When a team is spread over many locations it is important to put in place organization constructs to better enable these individuals to work together.
• Large amounts of cross organizational dependencies – When a set of requirements require a large amount of change outside of the domain that is driving the requirements it is important to put in place a project organization that includes all those different groups.
• Maturity of the team – Detailed planning and management is often only required when the team is staffed by practitioners who do not have a large amount of experience either in the organization or the problem domain.  The project organization provides the support necessary to enable them to be effective.

Does anyone have any experience on when not to use the structures of project to organize and manage work? Or do we need different types of projects to better manage the work, with some being lighter than others?