Search Results for: business model

Unraveling the Developer Bias in Agile Development Practices

by

There is a contradiction that shows up in many books and articles on agile software development.  .  And I’m going to rant a little on one of them: the “developer” bias in Agile software practices.

Before I begin my rant, I’d like to tell you where it comes from.  I am an Enterprise Architect.  I am also an agilest.  I am a certified Scrummaster (for many years) and have been on many agile projects.  I’ve seen success, and I’ve seen failure.  I know that agile is good, but not good enough to overcome people who are determined to undermine change. 

I am currently engaged on a project to help an organization rewire their business processes.  All of their core processes.  Some of them are in software development… and that is where agile comes in, but some are in other areas (sales, account management, customer service, etc).  I see it all, not just the software engineering bits.

To make this work, we created a set of principles that we use to drive the conversation around transforming the company.  We train people on the principles.  We connect change to the principles.  The principles are developed from the agile mindset but are not the same as the ones traditionally tied to the agile manifesto. 

One is focused heavily on the notion of an empowered team.  As the trainer, I’ve embedded these principles into my head.  Kinda hard not to.  So when I’m reading a book on agile practices, and the author says something that violates one of these principles, it stands out.  Big time.

And hence the rant.  I was reading Mike Cohn’s book on agile stories and I came across a passage that reflects a kind of mindset that does NOT build empowered teams.  And I went off.  The rest of this post is my rant.

—

On one hand, there is a basic expectation that we should empower the team to solve their problems using their skills and training.  On the other hand, there is a bias towards having developers involved in every part of a business process, from sales through requirements to project management and out to delivery and customer service.  The net result: we are empowering developers to perform every role.  No one else is empowered.  They are, in fact, not trusted at all.

At some level, agile practices like XP and Scrum are written, and promoted, by software developers, so it is understandable that these authors believe that software developers are a necessary part of every process.

But they are not. 

So what’s the problem

Organizations intentionally create specific roles and groups of people.  Those roles are defined to take the most advantage of the intrinsic motivations of people when performing their duties.  The things that motivate a person to become a project manager, for example, are rarely the same things that motivate a person to become a software engineer.  Motivation matters. If you are not motivated to excellence, you will not perform with excellence.

While it is fine for an individual person to be able to perform well in a couple of roles, it is absurd to build a system or business process that expects all people in one role to be able to perform another role well.  In specific, it is absurd to build processes where a technologist is required to develop requirements, or manage a project, or plan the delivery of systems.  Those processes can be performed just fine with motivated people who are trained and experienced in those activities.  However, to empower a team, people in these roles must be respected as well. 

Agile software, that so values people over processes and tools, demonstrates an utter lack of respect for the individuals who choose to excel in non-technical roles by asserting the need for developers to be involved in every step of their process.

For example, in XP (and sometimes in Scrum), user stories are described as being developed by a “customer team” that includes developers.  In the book “User Stories Applied,” Mike Cohn describes a process where a series of user roles are developed.  From those roles, the stories will be drawn.  The following is a quote from the book:

To identify user roles, the customer and as many of the developers as possible meet in a room with either a large table or a wall to which they can tape or pin cards.  It’s always ideal to include the whole team for the user role modeling that initiates a project, but not necessary.  As long as a reasonable representation of the developers is present along with the customer, you can have a successful session. — “User Stories Applied” by Mike Cohn

I’m an agilest, and this statement takes my breath away.  Why?  Because the SKILL of developing user roles is a good skill to have, but not a necessary skill for all developers to have.  Yet the author (whom I respect) assumes that the activity cannot be performed successfully without developers in the room!  At the same time, the text assumes that the task can be performed by developers exclusively (no one else is necessary at all).

The time that we spend training developers to be good at creating user stories is time that we are NOT spending training them on concurrent processing, idempotent messaging, and query optimization.  We don’t train business analysts or engagement managers on C# design patterns, so why should we train developers on user role modeling and requirements analysis?  It’s a total lack of understanding of the value of roles, and it is a bias that works against success.

What’s the solution: respect

 

Roles are not boundaries.  In any team, there are roles.  More importantly, as a member of a team, I have to trust my team members to fulfill their roles well.  If they need help, I TRUST THEM TO ASK FOR HELP.  When they do, I am happy to “cross roles” and provide help.  When I provide help, I am doing so from the perspective of a less-skilled resource, and under the supervision of the accountable role.  (e.g. if I “help” a tester, but don’t document a defect according to team standards, how much “help” am I actually providing?)

Roles are empowering.  If my team member does not ask for help, I trust each one to perform his or her role with excellence.  If I don’t trust them, how can they develop the excellence that the company expects?  How can they be recognized and rewarded for excellence if our processes and methods show a lack of trust in their roles to perform well without a developer present? 

Roles demonstrate respect.  As an agilest, I value people over processes.  That means I value the contribution of individual experts on my team to do their work with excellence, and I will show them respect for the work that they do, and the unique value that they contribute.  I will do so by allowing them to do their work without the “supervision and assistance” of a developer.

If they need me, they will ask for me.  Until then, I will get to doing what I do best.  I have a job to do, after all… and it is mine to do well.

Why this matters

Agile software development solves a problem.  The problem is that we are including waste in our processes, and that waste is causing software to be delivered late or with poor quality. 

If we optimize our processes, we can reduce waste. If we include developers in every process, we are not optimizing our processes.  We are, in fact, replacing one kind of waste with another. 

Services, customers and citizens

by

If we provide a service that is a monopoly or natural-monopoly, how should we relate with those who use our services? What’s the most appropriate metaphor to use, to guide our decision-making? I’ve been thinking hard about this for quite…

PwC’s CIO/CMO Roundtable with Geoffrey Moore

by

Guest Post by Ted Shelton On a recent evening in Silicon Valley, PwC hosted the well-known author Geoffrey Moore and 15 CIOs and CMOs from some of the leading Bay Area global technology firms. Over dinner Geoffrey led a spirited conversation on the new challenges that CIOs and CMOs are facing – rapid expansion of digital tools and techniques as a part of marketing activities; blending of marketing with other functional areas such as customer […]

4 Steps to Big Data Lite

by

Every time I breathe the words Big Data to a group of business and technology executives I brace myself for a barrage of questions…. How is it different? What’s our business case? Where will we source the data scientists to drive deeper insights? How do we acquire the technology to process mountains of information at a rapid-fire rate? The silent question lurking underneath them all: What if we fail? I’m not discouraged by their doubt. […]

Launching an Enterprise Architecture Program within State, Local, Municipal Organizations

by

When
launching a formal EA program, Government organizations often begin by
socializing the overall benefits of EA and developing an EA Charter and
Plan.  However, while both of these are valuable, they are more useful
as part of after-the-fact documentation and communication plans.  Having
worked with a broad spectrum of state, local and municipal government organizations across the US and Canada, our team, Oracle’s Public Sector Enterprise Strategy Team (EST), has found
that the first and primary focus in launching an EA program should be
on how to meaningfully engage top business leaders and other
stakeholders to discover their needs, identify what would bring the most
value to the organization, and obtain their buy-in and support for EA
as a key enabler in helping the organization achieve its mission
objectives. 

Launching an Enterprise Architecture Program within State, Local, Municipal Organizations

by

By Gloria Chou

When launching a formal EA program, Government organizations often begin by socializing the overall benefits of EA and developing an EA Charter and Plan.  However, while both of these are valuable, they are more useful as part of after-the-fact documentation and communication plans.  Having worked with a broad spectrum of government organizations across the US and Canada, our team, Oracle’s Public Sector Enterprise Strategy Team (EST), has found that the first and primary focus in launching an EA program should be on how to meaningfully engage top business leaders and other stakeholders to discover their needs, identify what would bring the most value to the organization, and obtain their buy-in and support for EA as a key enabler in helping the organization achieve its mission objectives. 

Why is launching (or re-launching) and EA Program relevant in the government space today?  Although state and local agencies may have had an EA team for years, many are just getting started on formalizing their practice and creating awareness of the team’s capabilities and purpose within the organization as a whole – though some are in fact successfully delivering Agency-wide Enterprise Architecture value.  Additionally, while a majority of Federal agencies have necessarily had established EA programs for over a decade in response to Clinger Cohen mandates, some are beginning to reshape their programs as they perceive the need to go beyond checkmark/compliance-based EA and demonstrate additional value to their respective organizations.  Governmental budget pressures are increasing the scrutiny on all resource allocation and deployment such that EA programs must stay relevant and drive acknowledged and desired benefits or else risk being cut.

I believe discovery and dialogue with executive leadership about their goals, objectives, strategies, and current planning processes has to come first as, only after this is known, can the team understand what is particularly valuable to the specific organization.  Too many Government EA programs seek to provide generic value and benefits, such as standardization and integration, that, while good aims in and of themselves, are not necessarily prioritized by the organization nor sometimes even compatible with their operating model and culture.  As a case in point, when working with a very large municipality in the West, the EST began discussing EA with a new, forward-thinking CIO who had been three months into establishing an EA program to change the way IT was viewed across the organization.  We had an initial meeting with the lead EA and found that the new EA team had been doing the expected: technology architecture current state analysis and building IT standards documents.  After three months, the team was well on their way to spending another year or more on documentation!  The question we posed was, how does this change the way IT is viewed across the organization? The answer was clear, it didn’t.  Understanding specific needs, gaps, and opportunities that the executives care about is essential to ensure EA is relevant and focuses on what the business needs to successfully execute on its strategies.   

Based on this understanding of the organization’s priorities and what would bring the most value, the EA team should analyze what needs to be done and propose how they can be a part of the solution.  In the example of the large municipality mentioned above, the EST helped the organization’s EA team identify areas of opportunity to engage with business leaders across the organization and facilitate meetings to better understand strategies, goals, capabilities and high-level value streams.  By starting here, we were able to get the EA team on a path to make better decisions on where they would invest their time to provide the most value to the enterprise.  As a part of this, the team needs to assess their own capabilities and competencies as well as that of other teams within the organization against what is needed and propose options as to how they might best help the organization and what other changes might be needed to achieve the organization’s goals.  In actuality, an EA approach would help facilitate this analysis and assessment of how EA itself could benefit the organization.  The team should consider developing the vision for change as well as current state and future state views of operations, analyzing the gaps, and developing recommendations and a roadmap for the successful introduction of EA into the organization.

Only after the recommendations have been presented, vetted, and selected by leadership should the team document the EA purpose, application, and approach.  While this information can be captured in the EA Charter and Plan, it only represents a part of the needed content.  The rest, especially the plan, can only be developed after seeking input from other stakeholders in the organization.  Even though the executives have weighed in with their input, direction, and approval, it is still often difficult to get an EA initiative started because so many other stakeholders also need to be convinced of the value.  For example, LOB leaders, business managers, and functional SMEs all have to be convinced of the value of EA or else they will not allocate the time and resource required to participate in facilitated sessions and verify/validate the architecture.  Executives and LOB leaders are critical in setting the vision for the future and describing the general goals for operations as well as communicating their overall investment and technology strategies.  However, even if the executives and leaders buy-in, the lower levels also have to perceive value/benefit or else they will put in minimum effort when you really need them to be fully engaged to provide detail as to the reality of operations, challenge the status quo of how things are done today, and ultimately take ownership of the architecture and support the transition to the future state.  Without the business fully on board, the EA recommendations and transition look good on paper but will never be executed. 

Similarly, other stakeholders including Corporate Strategy, Portfolio Management, Project Management, Lean/Six Sigma, and IT also need to fully support EA as they are also critical in the development, execution, and enforcement of EA.  The stakeholders in these other disciplines sometimes feel that EA encroaches on what they do and do not understand why it is necessary.  For example, Lean/Six Sigma practitioners and some business analysts already have great relationships with the business and have already documented and analyzed processes such that they believe they have already “modeled the business” such that EA business architecture development and analysis is extraneous.  IT organizations often point to their UML diagrams, systems engineering drawings, and infrastructure server drawings and say that they are already doing EA.  In seeking buy-in from these other groups, it is very important to first seek to understand and acknowledge the current state of operations – existing skills, processes, and assets – before proposing a future state of how EA enhances/complements.  Formal stakeholder analysis and RASCIs can be helpful, but I believe an attitude of respect for what others do and a collaborative approach is also critical as there are many organizational change issues and related sensitivities associated with introducing EA as a discipline as with any other transformation.  Once general buy-in and support for EA is established, the disciplines need to work out details around overall processes, governance, timing, inputs and outputs to understand synergies, cooperation, etc.  Again, this is something that can be documented via EA, further decomposing views that were used in the overall analysis for the introduction of EA.

Capabilities Demystified – Part 3

by

Assessing Business Capabilities Business capabilities have quickly become the core element of most business architecture models. Their appeal is largely driven by three factors. First, business leaders at all levels find capabilities an appealing and useful way to think about growing their organization’s impact. Second, capabilities are versatile, easily applied to high level strategic activities […]

Control, complex, chaotic

by

What exactly is ‘the chaotic’ in enterprise-architectures? How do we work with it, design for it rather than ‘against’ it? Yeah, I know this is a theme I’ve visited often here, but to me it’s a challenge that’s right at the core of…

6 Conditions for Success

by

bg outline

Ben Geller, VP Marketing, Troux
 

At our recent customer conference we took a moment to share the common characteristics we see in our most successful customers.  Since this was so well received by the conference attendees we thought it would be a good idea to share with a wider audience.

describe the image

  1. Start with the end in mind.  Seek business value and outcomes that materially impact the top and bottom-line.  If delivering business value is not your top priority – it should be.  Delivering anything less ensures your effort will be regarded as not being relevant.  Ignore an approach that puts business value at it’s heart more than once and you can be sure your Enterprise Architecture (EA) program will be destine to sit on the shelf along with all of the enterprise models and charts that have been created.  Our most successful customers always tie their efforts back to answering key questions business stakeholders want to address.  Take a look at one of our recent blogs titled ‘Doing the Right Thing vs. Doing Things Right’ – for more details.   
  2. Gain the Right Level of Sponsorship.  Another common trait we see in our most successful customers is their ability to obtain executive management support for their Enterprise Portfolio Management (EPM)/ EA initiatives.  Executive sponsorship is absolutely crucial.  Organizational change management is one of the hardest things in business.  If you don’t have executive sponsorship, you just aren’t going to get the organization to change its behaviors. For an EPM/EA program to be successful, you need participation from people outside the EA program. The executive sponsor does not need to be an EA expert or even care about the discipline of EA. But he or she must care about the results.  To read more about this condition for success see our blog titled ‘How to avoid common mistakes with your EA program – Part I’.
  3. Start Small and Market Internally.  A common mistake many EPM/EA teams make is based on a ‘Boil the Ocean’ approach to information gathering.  Gathering and assessing data can be quite seductive. But if taken too far it’s the equivalent of modeling the universe, and it’s a recipe for disaster. In fact if we see any problem today in our deployments, it’s that people get so excited they want to gather all their data at once.  It is also important to market your success internally. You secured support from the organization by promising something good for them, so make sure you go back and tell them you did it.  Then the organization as a whole can share in your success.  Read more about these success criteria in our blog titled  ‘Just say no to modeling the universe’.
  4. Collaborate Rather Than Dictate.  In a recent Wall Street Journal (WSJ) blog1 Michael Krigsman stated, “Modern CIOs must reconcile the gap between their role as protector of corporate information assets and the need to drive organizational innovation and openness.   We all are quite aware that promoting collaboration inside a large organization doesn’t just happen; it requires a thoughtful plan, coordination, and effort.  Enterprise Portfolio Management can help CIOs change the unwanted behavior that often is manifested by information hoarding and create a culture of collaboration by giving CIOs the means to shift the conversation from technology to business strategy and innovation.  See our blog ‘Lessons Learn from Social Networking’ to read more about EPMs role in institutionalizing collaboration. 
  5. Seek Value Early and Often.  Instant gratification is something we all have grown accustom.  The same holds true for business.  Programs and projects that deliver their intended results in short order are often viewed as benchmarks for other efforts to come.  Delivering value early and often should become a key part of any EPM/EA project teams battle-cry.  Our most successful customers have been able to go from project start-up to delivering quantifiable business results in a few short weeks.  Take a look at the case study from Scottish Widows Investment Partnership – a 2012 InfoWorld/Forrester EA Award winner to see how they delivered results in just 12 weeks. 
  6. Institutionalize and Embed in Process.  We have found that the organizations that achieve “best in class” results from their EPM/EA efforts are those that recognize that it is lifestyle change, not a one-time “crash diet.  To make EPM/EA a lifestyle change rather than a crash diet, an organization must commit first to “instrumenting” the business to measure the performance and business value of key enterprise assets such as applications, technology, business capabilities, investments and information.  By tying EA/EPM to key processes and initiatives such as application portfolio management, cloud migration, mergers and acquisitions, to name a few, EA/EPM teams will ensure the lifestyle change they deliver will have positive impacts across the enterprise.  For more examples of how to embed EPM in key processes read our blog titled ’Application Portfolio Management: Crash Diet or Lifestyle Change’.

     

    New Call\u002Dto\u002DAction

    Categories Uncategorized