Finding the Best Structure for Your Enterprise Development Team

by AgileBusiness ContinuityBusiness IntelligenceOperational Efficiency InitiativesOperational ReviewProject Management

An enterprise development team is a small group of dedicated specialists. They may focus on a new business project such as an IoT solution. Members of microteams cooperate with ideas while functioning semi-independently. These self-managing specialists are scarce in the job market. Thus, they are a relatively expensive resource and we must optimise their role.

Organization Size and Enterprise Development Team Structure

Organization structure depends on the size of the business and the industry in which it functions. An enterprise development team for a micro business may be a few freelancers burning candles at both ends. While a large corporate may have a herd of full-timers with their own building. Most IoT solutions are born out of the efforts of microteams.

In this regard, Bill Gates and Mark Zuckerberg blazed the trail with Microsoft and Facebook. They were both college students at the time, and both abandoned their business studies to follow their dreams. There is a strong case for liberating developers from top-down structures, and keeping management and initiative at arm’s length.

The Case for Separating Microteams from the Organization

Microsoft Corporation went on to become a massive corporate, with 114,000 employees, and its founder Bill Gates arguably one of the richest people in the world. Yet even it admits there are limitations to size. In Chapter 2 of its Visual Studio 6.0 program it says,

“Today’s component-based enterprise applications are different from traditional business applications in many ways. To build them successfully, you need not only new programming tools and architectures, but also new development and project management strategies.”

Microsoft goes on to confirm that traditional, top-down structures are inappropriate for component-based systems such as IoT solutions. We have moved on from “monolithic, self-contained, standalone systems,” it says, “where these worked relatively well.”

Microsoft’s model for enterprise development teams envisages individual members dedicated to one or more specific roles as follows:

  • Product Manager – owns the vision statement and communicates progress
  • Program Manager – owns the application specification and coordinates
  • Developer – delivers a functional, fully-complying solution to specification
  • Quality Assurer – verifies that the design complies with the specification
  • User Educator – develops and publishes online and printed documentation
  • Logistics Planner – ensures smooth rollout and deployment of the solution

Three Broad Structures for Microteams working on IoT Solutions

The organization structure of an enterprise development team should also mirror the size of the business, and the industry in which it functions. While a large one may manage small microteams of employee specialists successfully, it will have to ring-fence them to preserve them from bureaucratic influence. A medium-size organization may call in a ‘big six’ consultancy on a project basis. However, an independently sourced micro-team is the solution for a small business with say up to 100 employees.

The Case for Freelancing Individuals versus Functional Microteams

While it may be doable to source a virtual enterprise development team on a contracting portal, a fair amount of management input may be necessary before they weld into a well-oiled team. Remember, members of a micro-team must cooperate with ideas while functioning semi-independently. The spirit of cooperation takes time to incubate, and then grow.

This is the argument, briefly, for outsourcing your IoT project, and bringing in a professional, fully integrated micro-team to do the job quickly, and effectively. We can lay on whatever combination you require of project managers, program managers, developers, quality assurers, user educators, and logistic planners. We will manage the micro-team, the process, and the success of the project on your behalf while you get on running your business, which is what you do best.

The Child at Work: Fun Team Builds with LEGO SERIOUS PLAY

by AgileOperational ReviewProject Management

There is a child just below the surface in all of us. When were kids, adults lopped off the sharp bits that intruded into their ‘genteel’ society. Schools, to their everlasting shame sanded away our unique free spirits, as they stuck us into uniforms and imposed a daily classroom discipline. We received badges and prizes if we obeyed, and strict sanctions when we did not. This produced a generation of middle-age managers who no longer know how to play.

Life can be so deadly serious …

Things work pretty much the same in business. Life is deadly serious. If we want to keep our jobs, we must deliver on the bottom line in our departments. There is little time for fun outside the Christmas party, when we may, within the limits of decorum engage in activity for enjoyment and recreation, rather than a serious or practical purpose.

Team builds (and strategic planning sessions) can be deadly boring affairs that proceed down narrow funnels defined by human resource facilitators. No matter how hard HR they may try, the structural hierarchy will remain intact, unless they find a way to set it aside during the program. Injecting fun into the occasion liberates independent thought, and this is why.

… But not for a little child at play

Next time you dine out at a branded family restaurant, select a seat that allows you observe the kiddies’ play zone. Notice how inventive children become, when the family hierarchy is not there to tell them what to do (although parents may try from the wrong side of the soundproof glass). The ‘serious play’ side of fun team-builds aims to liberate managers by releasing their child for the duration. Shall we dig a little deeper into this and discover the dynamics?

Many of us have less than perfect oral communication skills. This is one of the great impediments to modern business meetings. We may not have sufficient time to formulate our thoughts for them to remain relevant when we speak. When we express them, we sense the group’s impatience for us to hurry up, so other members can have their opportunity to contribute.

Sharing better thinking with LEGO® bricks

Most of us feel an urge to click the brightly coloured plastic bricks together that carpenter Ole Kirk Christiansen released into a war-weary world in 1949. The basic kit is a great leveller because the blocks are all the same, and the discriminators are the colours and the power of our imagination. Watching a free-form LEGO builder in action is equally fascinating, as we wonder ‘what they will do next’ and ‘what is happening in their mind.’

Examples of LEGO Serious PLAY in action

Instead of asking team members to describe themselves in a minute, a LEGO® SERIOUS PLAY® facilitator may gather them around a table piled high with LEGO bricks instead, and ask them to each build a model of themselves. The atmosphere is informal with interaction and banter encouraged. It is still serious play though, as team members get to know each other, and their own personalities better

The system is equally effective in strategic sessions, where the facilitator provides specially selected building blocks for the team to experiment with as they learn to listen, and share. This enables them to deconstruct a problem into its component parts, and share solutions regardless of seniority, culture, and communication skills.

Creating problem- and solution-landscapes three dimensionally this way, enables open conversations that keep the focus on the problem. Participants at these team builds do not only reach effective consensus faster. They are also busy building better communication skills as they do.

Scrumming Down to Complete Projects

by AgileProject ManagementScrum

Everybody knows about rugby union scrums. For our purposes, perhaps it is best to view them as mini projects where the goal is to get the ball back to the fly-half no matter what the opposition does. Some scrums are set pieces where players follow planned manoeuvres. Loose / rolling scrums develop on the fly where the team responds as best according to the situation. If that sounds to you like software project management then read on, because there are more similarities’.

Isn’t Scrum Project Management the Same as Agile?

No it’s not, because Scrum is disinterested in customer liaison or project planning, although the team members may be happy to receive the accolades following success. In the same way that rugby players let somebody else decide the rules and arrange the fixtures, a software Scrum team just wants the action.

Scrum does however align closely – dare I say interchangeably with Agile’s sprints. Stripping it of all the other stages frees the observer up to analyse it more closely in the context of a rough and tumble project, where every morning can begin with a backlog of revised requirements to back fit.

The 3 Main Phases of a Scrum

A Scrum is a single day in the life of a project, building onto what went before and setting the stage for what will happen the following day. The desired output is a block of component software that can be tested separately and inserted later. Scrumming is also a useful technique for managing any project that can be broken into discreet phases. The construction industry is a good example.

Phase 1 – Define the Backlog. A Scrum Team’s day begins with a 15 minute planning meeting where team members agree individual to-do lists called ‘backlogs’.

Phase 2 – Sprint Towards the Goal. The team separates to allow each member to complete their individual lines of code. Little or no discussion is needed as this stage.

Phase 3 – Review Meeting. At the end of each working day, the team reconvenes to walk down what has been achieved, and check the interconnected functionality.

The 3 Main Phases of a Scrum – Conclusions and Thoughts

Scrum is a great way to liberate a competent project team from unnecessary constraints that liberate creativity. The question you need to ask yourself as manager is, are you comfortable enough to watch proceedings from the side lines without rushing onto the field to grab the ball.

Is Your Project Agile, a Scrum or a Kanban?

by AgileIT systems implementationKanbanScrum

Few projects pan out the way we expect when starting out. This is normal in any creative planning phase. We half suspect the ones that follow a straight line are the exceptions to the rule. Urban legend has it; Edison made a thousand prototypes before his first bulb lit up, and then went on to comment, “genius is 1% inspiration, 99% perspiration”. Later, he added that many of life’s failures are people who did not realize just how close they were to success when they gave up.

So be it to this day, and so be it with project planning too. There is no one size fits all approach when it comes to it. Agile, Scrum and Kanban each have their supporters and places where they do well. Project planning often works best when we use a sequential combination of them, appropriate to what is currently happening on the ground.

Of the three, Agile is by far the most comprehensive. It provides a structure that begins with project vision / conceptualisation, and goes as far as celebration when the job is over, and retrospective discussion afterwards. However, the emphasis on daily planning meetings may dent freethinking, and even smother it.

Scrum on the other hand says ‘forget all that bureaucracy’. There is a job to do and today is the day we are going to do it. Although the core Agile teamwork is still there it ignores macro project planning, and could not be bothered with staying in touch with customers. If using Scrum, it is best to give those jobs to someone else.

The joker in the pack is Kanban, It believes that rules are there to substitute for thought, and that true progress only comes from responsible freedom. It belongs in mature organizations that have passed through Scrum and Agile phases and have embarked on a voyage towards perfection.

That said, there can be no substitute for human leadership, especially when defined as the social influence that binds the efforts of others towards a single task.

Why DevOps Matters: Things You Need to Know

by AgileDevOpsLarge Scale ChangeTransformation

DevOps creates an agile relationship between system development and operating departments, so the two collaborate in providing results that are technically effective, and work well for customers and users. This is an improvement over the traditional model where development delivers a complete design – and then spends weeks and even months afterwards, fixing client side problems that should never have occurred.
Writing for Tech Radar Nigel Wilson explains why it is important to roll out innovation quickly to leverage advantage. This implies the need for a flexible organisation capable of thinking on its feet and forming matrix-based project teams to ensure that development is reliable and cost effective.
Skirmishes in Boardrooms
This cooperative approach runs counter to traditional silo thinking, where Operations does not understand Development, while Development treats the former as problem children. This is a natural outcome of team-centred psychology. It is also the reason why different functions pull up drawbridges at the entrance to their silos. This situation needs managing before it corrodes organization effectiveness. DevOps aims to cut through this spider web of conflict and produce faster results.

The Seeds of Collaboration
Social and personal relationships work best when the strengths of each party compensate the deficiencies of the other. In the case of development and operations, development lacks full understanding of the daily practicalities operating staff face. Conversely, operations lacks – and should lack knowledge of the nuances of digital automation, for the very reason it is not their business.
DevOps straddles the gap between these silos by building bridges towards a co-operative way of thinking, in which matrix-teams work together to define a problem, translate it into needs and spec the system to resolve these. It is more a culture than a method. Behavioural change naturally leads to contiguous delivery and ongoing deployment. Needless to say only the very best need apply for the roles of client representative, functional tester and developer lead.

Is DevOps Worth the Pain of Change?
Breaking down silos encroaches on individual managers’ turf. We should only automate to improve quality and save money. These savings often distil into organizational change. The matrix team may find itself in the middle of a catfight. Despite the pain associated with change resistance, DevOps more than pays its way in terms of benefits gained. We close by considering what these advantages are.

An Agile Matrix Structure – Technical innovation is happening at a blistering rate. The IT industry can no longer afford to churn out inferior designs that take longer to fix than to create. We cannot afford to allow office politics to stand in the way of progress. Silos and team builds are custodians of routine and that does not sit well with development.

An Integrated Organization – DevOps not only delivers operational systems faster through contiguous testing. It also creates an environment whereby cross-border teams work together towards achieving a shared objective. When development understands the challenges that operations faces – and operations understands the technical limiters – a new perspective emerges of ‘we are in this together’.

The Final Word – With understanding of human dynamics pocketed, a DevOps project may be easier to commission than you first think. The traditional way of doing development – and the waterfall delivery at the end is akin to a two-phase production line, in which liaison is the weakest link and loss of quality inevitable.

DevOps avoids this risk by having parties work side-by-side. We need them both to produce the desired results. This is least until robotics takes over and there is no longer a human element in play.

How DevOps Could Change Your Business

by AgileDevOpsLarge Scale ChangeTransformation

Henry Ford turned the U.S. auto industry on its head when he introduced the idea of prefabricating components at remote sites, and then putting them together on a production line. Despite many industries following suit, software lagged behind until 2008, when Andrew Clay Shafer and Patrick Debois told the Agile Conference there was a better way to develop code:
– Write the Code
– Test the Code
– Use the Code
– Evaluate, Schedule for Next Review

The term ‘DevOps’ is short for Development and Operations. It first appeared in Belgium, where developers refined Shafer and Depois’ ideas. Since then, DevOps became a counter movement against the belief that software development is a linear process and has largely overwhelmed it.

DevOps – A Better Way
DevOps emerged at an exciting time in the IT industry, with new technology benefiting from a faster internet. However, the 2008 world recession was also beginning to bite. Developers scampered to lower their human resource costs and get to market sooner.
The DevOps method enabled them to colloborate across organizational boundaries and work together to write, quality assure and performance test each piece of code produced in parallel.
DevOps’ greater time-efficiency got them to market sooner and helped them steal a march on the competition.

There are many advantages to DevOps when we work in this collaborative way. Cooperation improves relationships between developers, quality assurers and end users. This helps ensure a better understanding of the other drivers and a more time-effective product.

Summary of DevOps Objectives
DevOps spans the entire delivery pipeline, and increases the frequency with which progress is reviewed, and updates are deployed. The benefits of this include:
• Faster time to market and implementation

• Lower failure rate of new releases

• Shortened lead time for bug fixes and updates

The Psycho-Social Implications of DevOps
DevOps drills through organization borders and traditional work roles. Participants must welcome change and take on board new skills. Its interdepartmental approach requires closer collaboration across structural boundaries and greater focus on overarching business goals.

Outsourcing the detail to freelancers on the Internet adds a further layer of opportunity. Cultures and time zones vary, requiring advanced project management skills. Although cloud-based project management software provides adequate tools, it needs an astute mind to build teams that are never going to meet.

The DevOps movement is thus primarily a culture changer, where parties to a project accept the good intentions of their collaborators, while perhaps tactfully proposing alternatives. There is more to accepting a culture than using a new tool. We have to blend different ways of thinking together. We conclude by discussing three different methods to achieve this.

Three Ways to Deploy DevOps in your Organization
If you foresee regular DevOps-based projects, consider running your entire organization through an awareness program to redirect thinking. This will help non-participants understand why DevOps members may be ‘off limits’ when they are occupied with project work. Outsourcing tasks to contracting freelancers can mitigate this effect.

There are three implementation models associated with DevOps although these are not mutually exclusive.

• Use systems thinking. Adopt DevOps as company culture and apply it to every change regardless of whether the process is digital, or not

• Drive the process via increased understanding and feedback from key receivers. Allow this to auto-generate participative DevOps projects

• Adopt a continuous improvement culture. DevOps is not only for mega upgrades. Feedback between role players is paramount for success everywhere we go.

You can use the DevOps concept everywhere you go and whenever you need a bridge to better understanding of new ideas. We diminish DevOps when we restrict its usefulness to the vital role it plays in software development. The philosophy behind it belongs in every business.

Becoming Nimble the Agile Project Management Way

by AgileIT systems implementationProject Management

In dictionary terms, ‘agile’ means ‘able to move quickly and easily’. In project management terms, the definition is ‘project management characterized by division of tasks into short work phases called ‘sprints’, with frequent reassessments and adaptation of plans’. This technique is popular in software development but is also useful when rolling out other projects.

Managing the Seven Agile Development Phases

  • Stage 1: Vision. Define the software product in terms of how it will support the company vision and strategy, and what value it will provide the user. Customer satisfaction is of paramount value including accommodating user requirement changes.
  • Stage 2: Product Roadmap. Appoint a product owner responsible for liaising with the customer, business stakeholders and the development team. Task the owner with writing a high-level product description, creating a loose time frame and estimating effort for each phase.
  • Stage 3: Release Plan. Agile always looks ahead towards the benefits that will flow. Once agreed, the Product Roadmap becomes the target deadline for delivery. With Vision, Road Map and Release Plan in place the next stage is to divide the project into manageable chunks, which may be parallel or serial.
  • Stage 4: Sprint Plans. Manage each of these phases as individual ‘sprints’, with emphasis on speed and meeting targets. Before the development team starts working, make sure it agrees a common goal, identifies requirements and lists the tasks it will perform.
  • Stage 5: Daily Meetings. Meet with the development team each morning for a 15-minute review. Discuss what happened yesterday, identify and celebrate progress, and find a way to resolve or work around roadblocks. The goal is to get to alpha phase quickly. Nice-to-haves can be part of subsequent upgrades.
  • Stage 6: Sprint Review. When the phase of the project is complete, facilitate a sprint review with the team to confirm this. Invite the customer, business stakeholders and development team to a presentation where you demonstrate the project/ project phase that is implemented.
  • Stage 7: Sprint Retrospective. Call the team together again (the next day if possible) for a project review to discuss lessons learned. Focus on achievements and how to do even better next time. Document and implement process changes.

The Seven Agile Development Phases – Conclusions and Thoughts

The Agile method is an excellent way of motivating project teams, achieving goals and building result-based communities. It is however, not a static system. The product owner must conduct regular, separate reviews with the customer too.