My post on Overcoming Language Barriers facilitated some very nice sharing of resources. Executives and managers! You need to familiarize yourself with this information; you will benefit through improved understanding of what your IT projects should be doing for you:

1. Excellent discussion on Domain Driven development from Sensei at ActiveEngine’s Cool Stuff post. This is more than a software development discussion- it deals with how to attack problems from a value perspective as you develop “language” between technologists and users. I suggest reading the transcript and paying close attention to Eric Evans’ thoughts- great reading.

2. Great, and thankfully brief, agile software development glossary from Alex Howard via Margaret Rouse at IT Knowledge Exchange. Agile projects have proven their value- get a leg up on this value-driven approach to software development.

As a teaser, here’s some of what Sensei and I had to say about the Domain Driven development discussion:

Sensei: you may be aware of a movement within agile called Domain Driven development. The basic idea is that you allow the “problem domain” to drive the efforts of your technology development and implementation…in Domain Driven development the starting point is the business processes and logic; the database and screens become secondary considerations.

However – and this is a big however – the domain must be defined in very clear terms….developers must be able to write, in English, what the problems are using the business units language. It is also critical that it is written clearly so that the intent can never be misunderstood. Some may argue that UML does this, but most customers’ eyes will glaze over when presented with Use Case diagrams. When the problem domain can be described succinctly in common terms, your problem solving sessions will be more effective.

My theme lately with the development teams I work with is to build a working vocabulary; that is, pick one term to describe a process and stick with that term. In these sessions I have had to literally ask “And the word we use to describe this process is …?” ….if you are jumping from problem to problem, or worse, from project to project, you need strong definitions to keep things straight.

Bob: I scanned the Eric Evans interview; easy and good reading for non-technical people to understand that software developers should want to work on VALUABLE system changes; i.e., very interesting in that he justifies domain expertise as enabling focus on valuable-to-the-business processes which can be much more complex than the other areas because they tend to be revenue producing and customer facing. I enjoyed the discussion about new system complexity requiring an “anti-corruption” layer to interface to the legacy system that could take as much resource as the new system. Also asking “why are you buying this” to get at where to focus modeling efforts. The multi-language (technical model, user model, reconciled language) issue sounds just like what happens when two people speaking different languages begin to understand each other- my last experience like this was in Korea. Excellent insight into the minds of software developers!

Do you have these types of discussions with your IT people? Is a software development process driven by the business processes that are of high value to the organization a good strategy? Why or why not?

Don’t miss a post! Subscribe via RSS or EMAIL.

Post from: EveryJoe

Value Drives the Best Tech and User Collaboration

Intelligent Enterprise article “The Seven Pillars of BI Success” closed with a success story where agile software development processes came into play. 1-800 Contacts, winner of 2006 TDWI Best Practice Award, first aligned their BI project with a call-center-incentive project. The agile software development approach fostered high value innovative ideas to allow monitoring and improvement of agent performance mainly by giving the agents a way to monitor themselves. A large part of the success was attributed to the agile approach to collaboration with users:

Before picture: “Business would shout, and IT would do a fire drill and throw something out there.”

After picture: “Better communication with users and business leaders empowered to adjust priorities [through new governance model].”

As I said in my last post, BI and PMOs have similar requirements when it comes to the problem they are solving- decentralized, non-integrated projects and information that need to be prioritized and aligned with strategies. Interesting that agile processes facilitate the increased communication required for success in BI and PMOs.

The idea of empowering collaboration with agile approaches showed that IT can deliver something that gives business users value- mainly because they are getting more of what they want.

This strategic selection of the first “BI” project in an area of great interest to the company led to going down the road of leveraging information in other areas like marketing data mining and customer segmentation. IT is enthused by their successes and the users are enthused with IT.

What examples of IT/user collaboration have you experienced? Was it on a Business Intelligence project? Did agile software development collaboration processes come into play?

Don’t miss a post! Subscribe by EMAIL or RSS.

Post from: EveryJoe

Business Intelligence Projects Find an Ally in Agile Software Development

Margaret Rouse at IT Knowledge Exchange continues our conversation on PMOs. We started by talking about how a PMO relieves pain, then the PMO’s role in dealing with the dreaded mythical queue of projects, and now language barriers in agile software development projects .

My post on how previous experience with lean manufacturing might overcome some of the barriers in language and acceptance of non-intuitive concepts related to agile also comes to mind.

Here’s Margaret’s language issue followed by my response. Sensei at ActiveEngine! I expect you to get involved with this:

Margaret: I’m going to think more about how language remains a barrier to effective communication when the business owner is trying to articulate what they need to developers and the developers speak Agile.

Bob: Now you’ve got me thinking. I’ve been on the sales/project scoping side and the delivery side of projects. In selling and scoping my initial goal is to understand the client’s challenges in their terms and language . I try to resist the temptation to begin defining solutions until we have a solid agreement on what the problem is. Thereafter, as much as makes sense, the solution, and more importantly the value, should be in their language.

There is obviously a point where new terminology/concepts/approaches need to be introduced- the more we understand the business, industry, and the problems the better we will be at developing a conversation with common language to introduce these new concepts. This up front work and emphasis smooths out a lot of bumps in the road. Easier said than done because of all the temptations and distractions along the way.

*****************

What we are really talking about is developing the “salesman” in all of us; these concepts and approaches are covered more in a book about value selling which relate my experiences selling and scoping large business solution projects (see below).

What challenges do you have in developing communication with your customer (internal or external)? How much does the customer/client have to know about your processes (e.g., agile software development) in order to benefit from them?

Don’t miss a post! Subscribe by RSS or EMAIL.

FREE eBOOK for EMAIL Subscribers!

If you subscribe by email I’ll send you my eBook for free! Here’s how: subscribe by email in the right hand column PLUS send the email post that you receive to bob.turek@b5media.com. (Sorry for the extra step- we don’t have this automated yet.)

To preview the book, or to order a hardcopy, go to my publishing web site by clicking the book cover.

Post from: EveryJoe

Overcoming Language Barriers in Project Communication

Here is a slightly edited conversation with ActiveEngine following his response to my post on using lean experience to justify agile software development. It may be that non-IT executives don’t need to know about agile processes- just that the IT department is doing a lot more collaborating, testing and verifying throughout the software development process than they used to. I’ve found that lean is clearly different in this regard- i.e., proof of lean process success plus understanding the process is necessary for most executives in a company pursuing lean. Here’s the discussion:

ActiveEngine: Test Driven Development is more of paradigm shift for the developer than for the management, as the concept of “Fail, Inspect, Adjust, Acquire Goal” is easy enough concept in English to understand.

The hurdle for developers is to give up the idea that their spark of inspiration is what should be pursued; rather, you are forced to write your program code as a solution that answers a series of tests. These tests validate that “no book order to a customer of 3 years shall ship without a discount of 15%” rule is indeed implemented in by the program code. The idea is write no more code than is required to pass the test.

Here is a link to an Part 1 of a series that I am developing on Test Driven Development: http://activeengine.wordpress.com/2007/11/16/drive-by-specficiations-part-1/

PM411: Thank you for being a frequent commentor- I learn a lot from these communications. Given my experience is with lean, I’m curious as to methods to convince management that agile is the way to go. In particular, what experiences can you share on convincing non-IT management to engage in the collaboration required? or is the impact to non-IT not as big as I think?

ActiveEngine: Collaboration is so key. I have always positioned it as “Your opportunity to validate early on that the project is on track”. As you might expect, different departments will react differently to iterative cycles. One boost is that the accounting and finance types will like the tight cycles, or challenge and response as I call it, of spec creating and spec validation. 1 – 2 hours spent with spreadsheets laying out expected results and a follow up meeting with actual results really instill confidence that the product is on target.

PM411: So, it sounds like the IT management paradigm shift is the key. Does this mean that other department executives don’t need to know about the transformation? Do they normally learn about it from the bottom up? Lean is very much a top down and bottom up process because it does transform how a company manages, solicits information, and does work; and the changes, without an understanding of lean, are easily viewed by execs as upsetting the norm and distractions to the “real work”. Agile, once accepted by IT, appears to simply give users what they want.

Add to the conversation. What has been your experience with groundbreaking paradigm shifts? How important is the support for the shifts from executives from different functional areas?

Don’t miss a post. Subscribe by RSS or EMAIL.

Post from: EveryJoe

Fine Tuning the Use of Lean to Sell Agile

My discussion with agile software development project managers led to some great insights into overcoming barriers to agile transformation. I started by surmising that a company who had done lean manufacturing would be more likely to pursue agile software development. When asked why, I gave the example of “quality at the source” and compared it to the agile approach of test driven development (TDD).

Both approaches assess results closer to the creation (manufacture) of code (product). In manufacturing, the lean approach gives the operator power to assess quality and stop the entire process until the quality glitch is fixed. I grabbed my throwaway plastic cup with a vertical seam as an example. If the quality check is at the end of the cup making process, many thousands of bad cups may have been made before a bad seam process is detected. If the operator notices the seam opening and then stops the process, only a few bad cups will have been produced. Pretty basic stuff, but people, particularly cost accountants, will fight you on this approach.

The project managers emphasized that waiting to test code until the end of the development process yields similar results as quality checks at the end of the manufacturing process- a lot of code has been written and documented that may not work. Testing, or quality checking, at the source of the code, by the creator, catches problems earlier and reduces waste in the form of massive reworking or even throwing away code.

Lean manufacturing executives understand this and many other lean concepts that can be easily compared to the “manufacturing” of software code. Neither lean nor agile are intuitive. Having overcome the intuition barrier with lean, a lean executive is much more likely to embrace agile.

Tell me your successes/failures at using the lean/agile comparison. Do you think that an executive experienced in agile software development could be more easily convinced to embrace lean manufacturing?

Don’t miss a post! Subscribe by RSS or EMAIL.

Post from: EveryJoe

Can Lean Explain Agile?

Sometimes the conversations that we have on-line are revealing and illuminating. My recent discussion with ActiveEngine Sensei, who focuses on software development processes, allowed us to share lean, agile and best practice collaboration processes that drastically cut wasteful activity and accelerate business processes. He comes from a software development perspective whereas I come from a business process strategy perspective. Here is our unedited discussion:

Sensei: Bob- I agree with your position that project management is viewed as fix for broken processes. The PMO should be the “library” or internal consulting group that the units turn to when they need to embark on complex initiatives, as the PMO should have the best practices assembled from previous successes.

Numerous times I have heard “I don’t know how you are supposed to run a software implementation project.” The PMO should have the materials, although at an appropriate level, for a quick read. Better yet, would it not be great if one their peers had submitted a best practices 1 – pager? This communicates with people on a level that engenders the use of those practices before the crisis hits.

PM411: Sensei- The one pager best practice guidance is good because I believe that PMOs should “guide” and not “monitor”. I’m a big fan of a PMO helping to accelerate projects also and the idea that value of a project should trump cost. This aligns with agile software development- a quick look at your blog revealed software development experience- what do you think of agile methods?

Sensei: Although they are no panacea, Agile methods and Test Driven Development in particular can greatly enhances the communication process, as it focuses the developers on solving the customer problems with the customer as a partner in the analysis and creation of the solution. The developer(s) and the customer(s) write the test together, creating a single point of specification.Too many times I have witnessed the customer develop something WITHOUT the developers, deliver a spec, then demand budget and timeline. Now you’re on the fast bus to valley of frustration, as the developers need to re-work the “spec” to create something they understand. In the end you have two views of what the deliverable should be. Not what I would consider effective communication.

PM411: Yes! If only we would communicate- in software development, in selling, in management and in our lives outside of work. Software development is a fascinating process of communication followed by extended, creative work, followed by review/testing/spec changing that somehow reveals the power that communication methods can have on other processes. I’ll be doing a post on an article I read years ago about comparing agile methods to lean manufacturing that I’ll send to you. Us non-software developers have a lot to learn from your craft.

Sensei: I am on the quest to shorten the cycles between communication, analysis, development, testing and acceptance. The sweet spot would be to implement processes that capture the communications and turn those models that the discussion produces directly into workable products. In addition, the ability to adapt changes on the fly while not having to re-deploy the solution would bring great savings to an organization.

PM411: There is nothing like solving the problem NOW, assuming you have a workable solution, versus delaying with wasteful “time to think about it”, “get opinions of others”, “formulate an email summary”, “create a spec”, etc. I’m reminded of a lean vs agile comparison in which the “inventory” of a software development project is documentation- i.e., most documentation is “waste”. Working the NOW way forces you to collaborate and move ahead- so much more can be accomplished. My most recent example is in a packaged software sales process where a typical multiple phone call and multiple visit “sales cycle” is short circuited by first agreeing on the problem to be solved and then the value of solving the problem; the typical approach is to present the generic solution first which usually causes a huge disconnect that must be unraveled through wasteful communications.

Post from: EveryJoe

An Agile, Lean Communication