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?

A great article in Strategy+Business, “A Blueprint for Strategic Leadership”, concentrates on how to lead innovation. In it the authors emphasize that the best leaders pay a great deal of attention to the design of the elements around them. Seemingly basic, but powerful, things to do are:

1. Articulate purpose,
2. Create effective teams,
3. Prioritize and sequence initiatives, and
4. Redesign the organization to make execution easier.

Apart from revealing the importance of doing the right projects, the article is full of fascinating examples of the deployment of these principles by the best executives; two from the experiences of A.G. Lafley, chief executive of Procter and Gamble, stood out:

1. Moved the divisional presidents’ offices nearer their staffs, converting the old executive space into an employee learning center. This is not only practical but sends a message that they are serious about creating an environment for innovation.

2. Plans careers of top 500 people by reviewing assignments, capabilities, and how he can help them grow. This goes beyond periodic performance reviews to showing a genuine interest in how the organization can help develop the careers of people.

You don’t have to be a CEO to pay attention to the design of the elements around you. How can you incorporate the four “things to do” into your management style?

Don’t miss a post, SUBSCRIBE via RSS or EMAIL.

Post from: EveryJoe

How to Make An Organization Fly

A Booz Allen Hamilton survey and report in Strategy+Business (register for free) found NO correlation existed between R&D spend and innovation. It turns out that higher innovation performers spent less but made sure that innovation projects aligned with corporate strategy and paid careful attention to customers. This idea that a company can spend less and innovate more makes sense. Throwing money at innovation processes that are not well organized and/or measured and not serving the customer doesn’t work.

Black and Decker revealed the two key factors related to their innovation success:

1. Strategy alignment- align innovation strategies to corporate strategy.
2. Customer focus- processes are in place to pay close attention to customers from idea generation to product development to marketing.

Although this article tended to focus on product innovation and R&D spending, Black and Decker’s customer focus reveals that business process innovation is often required to coincide with product changes. One example is a strategy project I worked on for a metals distributor where we segmented the customer base a variety of ways to discover which segments were willing to pay for inventory management services. The change in what was being sold and provided affected sales processes, how inventory was managed, frequency of delivery, and ultimately how raw material and components were purchased. This clearly reveals how market based projects can affect internal business processes.

Excellent project management was a key success factor for these high innovators. The authors revealed the “one R&D tactic” used by all high-growth innovators:

“insistence on managing the innovation process from start to finish as tightly as possible…a disciplined stage-by-stage approval process combined with regular measurement of every critical factor, from time and money spent in product development to the success of new products in the market…combined with a strong portfolio management program…”

Sounds like strong project management and project portfolio management are basic preprequisites for successful innovation. What do you think? Does all this apply to a small company?

Don’t miss a post, SUBSCRIBE via RSS or EMAIL.

Post from: EveryJoe

Spend Less While Innovating More? Yes!

Sometimes you get unexpected insights. My post “What’s Harder? Project Management or Management” elicited a wonderfully simple “boxes” analogy from Ren Garcia at Accounting Solver. In it he said:

“In a standard hierarchical corporate organization, you have specializations through boxes (i.e., departments, divisions, sections, etc) identifying finance, marketing, production, human resources, etc. Frequently, the specializations become rigid over time and the boxes neglect to communicate with each other (The managers or heads of boxes are supposed to be doing this, but often neglect).

Consequently, integration of all the functions / tasks / responsibilities within the corporation becomes a difficult process. The entire organization needs to be on the same page and move towards the same goal. What you don’t want to happen is one box (function / task / responsibility) undoing what another box is trying to put together. A classic example is the finance department trying to bring down accounts receivable and the marketing department keeps giving credit…

Projects & Project Management bring together managers and technical / professional staff and is a potent form of integrating an organization that has become too specialized. Without any extra effort at all, boxes (departments / divisions / sections) talk to each other more frequently and productively and get to understand what the other boxes are all about. In a project team, the talk is not all about the project and there can be a lively exchange about non-project issues, including relevant corporate-wide issues.”

Ren’s insights elicited my (mildly edited) response:

“Ren- nice analysis. The boxes analogy helps. I’ve been referring to the divisions as “silos” but “boxes” better aligns with some current thinking about “getting outside the box” related to innovation. Also, I appreciate your view that project management facilitates breaking down the barriers between departments.

One of the first things that one strategy consulting firm does is to simply have all executives present to each other about what all the other departments are doing. This enables executives to do a better job of determining strategies and creates the cooperation necessary to later execute them.”

As I recall Ren had some hesitancy to comment on my blog because he felt a little intimidated by the subject matter. I, of course, knew better and encouraged him to offer his views. Now I need to comment on his because he obviously has a lot to say.

What’s holding you back? I’m sure you have something to offer.

Don’t miss a post, SUBSCRIBE via RSS or EMAIL.

Post from: EveryJoe

Organizations as “Boxes” Analogy Reveals Power of Projects

 

Fascinating conversation with an executive of an agile software development firm about transformation projects as they compare to lean manufacturing initiatives. Lean transformations have settled into starting with training heavily laced with practical activities. The reason that this is so important is that the approach is NOT intuitive.

Lean requires a person to experience how the concepts can change and increase the value of a process, whether it be software development or manufacturing products. One of the most valuable exercises is the traditional lean manufacturing simulation consisting of 4-5 iterations of improvement to clearly reveal how each lean concept influences results. Many times an executive level version of this simulation kicks off a lean project because of it’s powerful way of revealing the value of lean principles. For more on lean look at the excellent web site www.leanexecutive.com.

The paradigm shift is the most difficult barrier to overcome in both lean and agile. The agile company used to have a client strategy of doing an agile project first followed by a transformation project. The current approach flips the order to start with transformation efforts with “practical” training. It’s remarkable how similar the lean and agile approaches have evolved AND there is much to learn from being a student of both. For example, my post on agile estimating serves the lean community well. As techniques and approaches are proven out in each area, innovative application to the other area should be considered. This is a great example of looking outside the four walls for business process innovation.  

Let me know what you think about how lean and agile compare to each other.

Don’t miss a post, SUBSCRIBE via RSS or EMAIL.

Post from: EveryJoe

Agile Transformation Strategy Is A Lot Like Lean

A recent September 2007 Gartner study titled “Building Agile Manufacturing That Enables Transformation” made several great points:

1. Changing forces in market, customer expectations and technology demand more agility and quickness in business processes.

2.  Using a ”myths” leading to “misses” discussion they challenge people to look outside their environment for innovations saying that people and companies tend to “lock in” to solutions because of tradition and inability to search outside their four walls.

3. ”Chaos-tolerant” business processes are what is needed in the future. Using a technique called capable-to-promise as an example of chaos-tolerant business processes, they say that future technology will enable them.

Capable-to-promise is basically the ability to quickly determine if a customer order is doable by considering both material and capacity constraints simultaneously.

My one disagreement is with the point that chaos-tolerant business processes require whiz bang technology. My experience with a solution in the on-time shipment area reveals that the innovation lies in it’s simplicity, not it’s technology; plus it has the ability to transform information already in current systems to drastically increase the productivity of knowledge workers like planners and master schedulers. It’s lack of whiz bang is what makes this solution so easy to evaluate and implement. The proven value of 20-30% throughput and inventory improvements by eliminating data collection and expediting activities in short-term prioritization efforts is chaos-tolerance at it’s best. 

Don’t miss a post, SUBSCRIBE via RSS or EMAIL.

Post from: EveryJoe

Agile Manufacturing Enables Transformation