Category: Methodologies

Maturing from a StartUp to a StartedUp culture

The content for this discussion is several pages long so I will release it in posts as a series.
Introduction

A couple of weeks ago I had interesting discussions with a software lab focused on mobile tech out in the Boston, MA area. Ideas were exchanged, we spoke about different issues that impact teams, growth, product, process and discussed different ways they could be solved.

After the dialogue, reflecting back on the content and looking for a root cause or pattern I realized that this wasn’t the first time I had discussed or worked on solving these type of issues; growing pains, single threads, lack of process, maturation are just some of the terms used to describe the root cause and in most cases its all of them as they mean the same thing and to me that is “growing startup culture”

A startup company or start-up from http://en.wikipedia.org/wiki/Startup_company

A startup company or startup is a company, a partnership or temporary organization designed to search for a repeatable and scalable business model.[1] These companies, generally newly created, are in a phase of development and research for markets. The term became popular internationally during the dot-com bubble when a great number of dot-com companies were founded.Lately, the term startup has been associated mostly with technological ventures designed for high-growth. Paul Graham, founder of one of the top startup accelerators in the world, defines a startup as: “A startup is a company designed to grow fast. Being newly founded does not in itself make a company a startup. Nor is it necessary for a startup to work on technology, or take venture funding, or have some sort of “exit.” The only essential thing is growth. Everything else we associate with startups follows from growth.”

And from the same source, a startup culture

Startups utilize a casual attitude in some respects to promote efficiency in the workplace, which is needed to get their business off of the ground. In a 1960 study, Douglas McGregor stressed that punishments and rewards for uniformity in the workplace is not necessary, as some people are born with the motivation to work without incentives.[11] This removal of stressors allows the workers and researchers to focus less on the work environment around them, and more at the task at hand, giving them the potential to achieve something great for their company.

This culture has evolved to include larger companies today aiming at acquiring the bright minds driving startups. Google, amongst other companies, has made strides to make purchased startups and their workers feel right at home in their offices, even letting them bring their dogs to work.[12]The main goal behind all changes to the culture of the startup workplace, or a company hiring workers from a startup to do similar work, is to make the people feel as comfortable as possible so they can have the best performance in the office.

This is what most of us understand startups to be; but I would argue that startup cultures do not only apply to a new or young company (a startup) or that the culture is inherited through acquiring a startup; applying the culture and model that exist in a typical startup one can “build startup culture”.

If startup culture is a “must have” then how can there be any issues with that culture? To clarify, in my opinion startup culture is great, they build great teams, focus on product, have a great culture and are fun to be in – and I respect and thrive in them; you start running into issues once the startup has started-up and you need to scale three core P’s: people, product and process. For me, the key is using teamwork and relying on your peers to figure out how to scale all three at the same time while everyone is busy with their other workload.

The next post will outline some of the end-products of startup-culture that should be addressed/changed in order for the startup to mature as it goes from being a startup to started-up culture

Advertisement

Rapid Agile – Real-time Actionable Prioritized Individual Delivery

So what does come after Scrum/Kanban/Agile?

The evolution of the SDLC continues as expected and if you look at the trend, the focus has been to get things done quicker – Rapid.

Andy @ Assembla calls it Scalable Agile and has great content explaining the concept behind it; I call it Rapid – Real-time Actionable Prioritized Individual Delivery, or Rapid Agile and the basics around the process are very similar. The focus or goal is to prioritize individual efforts rather than a team sprint, act upon real-time feedback and  deploy much quicker; often deploying new features and bug fixes several times a day rather than ever other week or so.

Case Study: Blank Label

At Blank Label when we were much younger, we manually deployed whenever we wanted as we were trying to rapidly enhance and stabilize our offering. With every feature came a lot of bugs and it was usually the changes in usability that brought inconsistency in usability as we had limited resources and a lot of “to-do’s”. Eventually we settled on a 2 week delivery cycle  but as we were attempting to find out who our customer was, we made some drastic changes only to see orders drop from several a day to almost none every week. We had no idea what of the 20 things we changed in the 2 weeks that killed it as A/B testing had told us that our sales would go up, not vanish.

Fast-forward many months – we saw that we had gone back to our old habits, but this time we had process and we were not disrupting things when we updated, we deployed to a staging server, tested things out there and then released to the live server. This still required manual builds and deployments, many times fixes just didn’t make it to the live system when issues were discovered because it required someone to build and upload…

Now fast-forward to yesterday – we now build the backlog in Jira and make use of green-hopper for their kanban board. We go through a to-do, doing, build and live workflow, where bamboo will automate code checkins and deploy with AWS ec2 to our staging server; once testing passes staging, the deployment to live is a simple click of a button and live is then refreshed.

For test, we have gone from  1-3 pushes to test per day to 5-8 pushes per day and for live will be going from one refresh per day to 2-3 refreshes. We still have a small team of developers, once this team grows we will probably see a large increase in pushes to test, but will probably maintain the 2-3 refreshes to live per day (depending on the functionality).

In the not so distant future, I will provide the development workflow process along with the tutorial to build all the Atlassian stuff that will get you to a rapid continuous integration, deployment and deliver model as I did not see a lot of solutions that focused on the .Net MVC3/4 Razor stack.

Building a dynamic onboarding program for Martians

Chances are that you have been through some form of schooling (high school, college, maybe some random instructional education) and have hopefully figured out that everyone learns differently.

For me, learning and passing my classes meant that I showed up to all classes, took no notes – just listened and the day or so before a test or final, skim through the text books (if i had purchased them) and then just showing up for the tests. Once I figured out how to do that very well, my last 3-4 semesters for my Bachelors, Comp Sc were filled with A’s and my Masters, Software Eng was a solid 4.0.

Was  it a piece of cake? Nope, but I surely made it seem like it was.

So whats the secret? or whats the relationship to that with onboarding? or well what is onboarding?

From Wikipedia

Onboarding, also known as organizational socialization, refers to the mechanism through which new employees acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders.[1] Tactics used in this process include formal meetings, lectures, videos, printed materials, or computer-based orientations to introduce newcomers to their new jobs and organizations. Research has demonstrated that these socialization techniques lead to positive outcomes for new employees such as higher job satisfaction, better job performance, greater organizational commitment, and reduction in stress and intent to quit.[2][3][4] These outcomes are particularly important to an organization looking to retain a competitive advantage in an increasingly mobile and globalized workforce. In the United States, for example, up to 25% of workers are organizational newcomers engaged in an onboarding process

Some organizations have great onboarding programs; some don’t. There are going to be cases where you inherit a team that has single-threaded subject matter experts and as a manager you may be expected to distribute that knowledge and grow the team – with no process or onboarding program in place. Yes, you have to create it, so where do you start?

Do you invest time in meetings? create videos? printed materials? who will read all that? who will do the work if your team is off training new hires? is that really a good use of their time? or a real-world question “Do you have bandwidth?”. The answer is No.

So, why not use what you, or I learnt during schooling? when we ourselves were learning? how did you learn? How could you create an onboarding program from nothing? and how could you be sure it would work? You really do not want to invest time in something that is  not going to work so it needs to be agile enough to change on a whim.

Okay – enough of the red flags, here is what I did. Ill try to make this as generic as possible.

I inherited a team of martians, and the problem is that they only speak a special language, called martia. Turns out that its a very ancient language and that no one really speaks martia nor is it taught in college. The small group of martians have been speaking it for 15 years and they as a team are great at it, theres just a few of them. It also turns out that there are all these documents that come in that need to be checked for grammar and spelling, and corrections – in many cases the martians really have to research and see what the intent of the document was because in some cases they have to re-write the document correctly – it can definitely be time consuming and this is the only team that can do this.

This team of martians is also aging, some have retired, others were move to other planets so I have to hire more martians – but, there are none around. So I hire a martian from a different universe and tell it that it needs to learn martia and I will help it learn this language; the language it speaks, we dont care for it. Here is the process that gets put in place

1. Every day the new hire will sit with a senior martian for 2-3 sessions and learn stuff

2. The sessions will be 30 minutes long and after every session there will be a break, during which the new hire will document all that was covered

3. During the next session, the senior martial will review notes, as a refresh to where they left off, and continue the information offload

4. Steps 2 and 3, repeat for a week or so; after which the new hire will then attempt to work the documents

5. as the new hire works the documents, it will have questions, it will document them

6. the new hire will setup additional sessions with the sr martian to get clarification and answers

So – you say this is just common sense and normal stuff.. how are we reducing the dependency on the sr martian who is already busy? here is the answer:

A couple of months go by and another new hire is brought on

1. The new hire sets up sessions with the x-new hire, i.e. the junior martian.

2. the new hire reads all the documentation created by the junior martian

3. several sessions take place where the junior martian and new hire go over content

4. a session every now and then takes place where the sr martian comes in to listen in, and see how the training is going

5. if the sr martian adds anything, its documented in the growing on-boarding document

6. the new hire then also attempts to work documents and goes to the junior martian for assistance – and if needed, they both go to the Sr. martian.

So, its somewhat like train-the-trainer you say…. yes, it is., except, the trainer role gets passed down to the newest hire. if you keep hiring, you start building a 2-tier training team, where the junior martians, through teamwork, will try to come to a conclusion, and then will be empowered to go to the senior martians for confirmation. This helps build teamwork, confidence and helps them acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders.

Sooner or later, your team of martians will grow and the martia language, once so uncommon, will become common and the perception that its the monster in the closet that only the select few can understand, soon goes away.

Beginning Process Improvement – What to do first

“Existing processes must be described before they can be well understood, managed, and improved. An organization must then define what these processes should be before attempting to support them with software engineering tools and methods; in fact, the definition forms the requirements for tool and method support. A variety of process description and definition technologies is available.” [*]

Ask a gardener how you can improve your software development practices and not only will you get a strange answer, you will also get a very confused look; unless of course the gardener use to be a software developer and knows your product (and current process) in an out. In other words… if one does not understand the inner working of things, such as the current chaos (or processes) or what goes on behind the scenes and how things work, then that person cannot provide you with useful information on how things can be improved.

A defined process is a prerequisite to process improvement; you cannot (well you could, but it would take quite a while) improve process without understanding what it is you are improving and how the change’s that are suggested and implemented will affect other processes.

As obvious as may sound; to begin improving process, you need to first draw it all out and identify all the bottle necks/issues one by one and strategize when and how to improve what. Many have wasted their time trying to implement something that may have worked elsewhere, or something that’s out of a book that’s there for the sake of “having a process” with no real benefit to the users.

When it comes to process – One size does not fit all.

[*] – Technical Report “Software Engineering Process Group Guide”. Flower, P & Rifkin, S, September 1990. CMU/SEI-90-TR-024, ESD-90-TR-255

Horizontal Management – Maintaining momentum: Keep progress moving

While machines might give the same level of output everyday, the same doesn’t apply to people.

In a real environment, each member’s momentum and motivations will change without notice. This requires management to step in and make sure they are constantly evolving the processes so that members will remain motivated. Leadership is important to motivate key players, channel information to keep everyone engaged and make working horizontally routine. To accomplish this, management might bring in an outside champion, who will help wring in new ideas and “fresh” stream of motivation. Instead of looking at a project as a whole, it should be broken down into smaller goals that are realistic and achievable. Management should encourage and build on small success, to demonstrate that it was an important milestone and motivate members. Progress and results should be demonstrated so that members can all acknowledge the ongoing progress and success.  Management can keep the members interests by ensuring that they are always focused on achieving the goals that were set, and if deviation is detected, corrective action is taken to bring things back on track.

A horizontal team is dynamic as it is always changing, management needs to account for its dynamic nature and make necessary adjustments to accommodate/adapt to the change. Money is probably the best motivator, but too much money too early in the process can hinder individual initiative and prevent people from innovating. Since horizontal structures focus on team collaboration, a downfall is that meetings can go on forever and schedules can be missed; this can unmotivated some members who feel that decisions are not being made in a timely manner, which is why management can implement deadlines which will help practitioners develop a common schedule and manage workloads effectively so that the projects momentum is kept at a steady pace.

[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]

Horizontal Management – Building support structures: To keep Horizontal team in check with Vertical roles

Even though a “horizontal structure” is flat in nature, it does still need a (vertical) support structure.

The main purpose of a support structure is to help managers build lasting relationships and achievements with teams. There are two basic type of support structures that managers can mix and match when building or working with teams, depending on the requirements as each has its own attributes.

  • Informal structures don’t define rigid roles and responsibilities, they are open to interpretation and people can define their own roles and swap roles as needed, hence they are less resource intensive, more flexible and less binding on members; Informal structures help promote open discussion and communication among its team members; and
  • Formal structures are more rigid and roles/titles might be defined where members have specific responsibilities; this makes them more resource intensive but less ambiguous; they require some logistical skill and expertise to implement. These structures are great when consistency and quality are important factors.

It’s important for management to recognize what type of structure needs to be in place and when its put in place; as “when” a structure is erected, it can play an important role in the success of the teamwork initiative. If too much formality is introduced early, people might feel there is no difference in the “horizontal structure” and the “vertical structure” where vertical structures are rigid, formal and bureaucratic and would be less motivated to work with the initiative. In contrast, waiting too long to build a support structure or the lack of a support structure can hinder the ability of the team to successfully work together as a team, especially when they need to be able to adapt when in tight spots.

Since the resources and effort required are greater when setting up formal structures, informal structures are great for short projects, however when the projects will go on for a long period of time or are of large scale, formal structures would be more suited as they are less ambiguous and will stay well formed longer (as they are more solid than informal structures).

Authority and roles in informal structures are more ambiguous and can be swapped around; In formal structures, the roles and responsibilities are more definitive, hence less ambiguous and in that regard, formal structures would work best in situations where important decisions need to be made.

[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]

Horizontal Management – Developing shared framework: Working for the same goals

When we work as a team, we usually work for the same goal(s). There will be times when we might stray away from the goals that were originally specified and we will not realize it. By developing a shared framework we can help ensure that we are all (still) working towards the same goals.

Image

With open discussions, patience and a shared fact base (mental model and vocabulary) we can deal with conflicts internally (within the team) and develop a shared understanding of the key issues.

One major issue of working with a team is accountability, as many forget their individual accountability and it becomes unclear where the accountability lies (does it lie with the individual, or a team as a whole?). This is probably because the lines of individual accountability and the shared sense of purpose become unclear because of the focus and emphasis on the “shared” attitude towards everything and it is important to acknowledge the difference and maintain the separation. Clarifying roles, responsibility, shared goals and results upfront with open discussions and debate will help resolve accountability issues in advance. We might need to revisit and re clarify these elements as they might evolve over time due to changing circumstances and new opportunities. Having a shared and clear understanding of planning and reporting can help accomplish all these tasks (involved with developing a shared framework).

[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]

Horizontal Management – Mobilizing team and networks: Ready for action

A team that does not work well not only is not a team; but is a blocker towards any success. It is a team (not) that does no work. – yes the not is from Borat.

We must be able to organize teams and networks to be ready for action as this helps the team get off the ground and moving. In order to help get things going as smooth as possible we can focus on a few key elements that can build teamwork and networks, these are leadership, teamwork attitude, common understanding and trust.

Leadership: In my experience, I have always enjoyed working on projects when I was able to be the leader, I think this is inherent to our nature that most of us want to be leaders instead of followers as it makes us feel important and think that we have make a significant contribution to the project. When working as a team, one of the great benefits (that most do not realize) is that the leadership can be shared equally among the team members, it can and should shift from person to person depending on what is required and the person’s strengths, this gives everyone a feeling of accomplishment and an equal and important say in the processes (even if it may not be). When working horizontally team members should be allowed to have debates, open discussions as they are key methods of identify opportunities and resolve conflicts that may arise….. so long as you can focus and move forward.

 Teamwork: Rewarding team members to play nicely as a team always gets peoples motivations up. Teamwork makes a horizontal partnership cohesive so management should encourage early team building activities and open engagement that help develop a sense of collective ownership. This can be encouraged by giving incentives to work successfully as a team, such as recognizing members for their team efforts by giving awards and rewards.

Common Language: Recently I worked on a project where I was using the phrase “data entry” to describe an action where “any user enters data using a graphical user interface”. One of the team members was having a very hard time following the discussion because to him “data entry” was specific to “data entry personnel” (people hired to do data entry), who used a specific data entry user interface that was different than the user interfaces used by others, this was because they didn’t need the pretty features as all they did was repetitive data entry. This is why it becomes very important that the team members have a common mental model and have developed a vocabulary that is understood by all as this helps develop a working culture where misunderstandings or unclear terms will be kept to a minimum.

Trust: Trust is very important in maintaining relationships, it is the glue that holds a team together, if someone does not trust other members in a team, or does not fully place their trust in the team they will not be completely open and might not want to take part in discussions or coordinated efforts. The need for trust makes it important to invest in relationships and build credibility, this can be done by undertaking small tasks, being open and honest with others and delivering what was promised. When team members trust each other they will be willing to risk more together.

[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]

Working Horizontally (agile) & understanding Horizontal Management (work/team structures) and its issues

In line with the content on SDLC and ALM, along with today’s needs and desires for teams to be more flat.. or vertically structured: My next few posts are going to be about working horizontally, or horizontal management (work/teams/structures), or. let me throw in a buzz word .. “working in a more agile manner” 🙂

Horizontal management is: about working collaboratively across organization boundaries. There are no hard and fast rules to horizontal management it is an art more than a science. This type of management is pervasive, occurring at entry level in an organization. It involves bringing people from diverse organizational and occupational backgrounds together into teams and networks with a common purpose and shared culture. Group thinking is encouraged, but this can be seen as a risk because it cuts lines of accountability and authority and pursuing consensus at the expense of serving the public interest.  [*]

In a nutshell, working as a team/group is working horizontally. One might think that working as a team is an easy task as we all have done so at some point in time, but this is not the case when teamwork is the bases that can make or break the success of an initiative, especially when used in complex processes like software engineering and process improvement and we are in a teamwork state for long periods of time. There are various dynamics that come into play when working as a team, for example some might not get along or trust other members, some might not be motivated or good team players and others might forget their individual responsibilities. Working as a team requires that everyone get an equal part so that everyone has an equal interest in working together, towards a common goal, build long term relationships and be equally motivated for the long run. An interesting relationship between horizontal structures and software development is that working in a horizontal structure is viewed as an art, which is the same way that software development was viewed as before it was realized that it needs to be a manageable process, our focus will also be to help make horizontal management a manageable process.

Some of the issues that horizontal structures bring with them that need to be addressed are:

  • Working with others as a team slows down fast paced, ready for action members
  • Members are sometimes not motivated enough to work as a team, which damages team effort and progress
  • Members usually trust their own judgment and find it hard to put that trust in the hands of others
  • Each member may have their own vision and own motive, maybe a goal they want to accomplish as part of their job function and have their own priorities.
  • With everyone on the same level, who provides direction and leadership? Who is held responsible?
  • People need to be assured that their time and effort is resulting in progress.
To understand and address these issues, we need to have a look at the various “dimensions of horizontal management”

Key Dimensions of horizontal management

Working as a team rather than working as an individual does bring with it a few issues that need to be addressed:

  • When we work alone it is easier for us to switch gears and start making progress because we don’t have to wait for others to be ready, progress begins when oneself is ready, in a team progress begins when “everyone is ready”.
  • When we work alone we know what our goal/vision is, we know what we want and know how we are going to get there if we start straying away its really easy to pull ourselves back; When we work as a team, its possible that not everyone knows that the common goal is, they might have their own goals or own ideas of how things need to be and what takes priority over the other, when working as a team its important to make progress by combining all efforts towards a “shared goal/vision”.
  • Working alone means that you are responsible and accountable, you need to get the work done and you need to manage your own time, when working as a team, who does what gets blurred this is why a “support structure” must be in place (depending on the requirements) so that vertical roles and responsibilities are not forgotten.
  • When you work alone, since you are in control (and responsible) of the progress, it is easier to maintain your momentum, you know how much progress you have made, you know how successful you have been and if needed can make changes to help maintain momentum; Teamwork introduces attributes that may effect momentum such as meetings that go on forever, goals that seem unrealistic or far fetched, not knowing if all the effort in working as a team is paying off or not and so on. When working as a team, we must be able to “maintain momentum” on a daily bases.

Hence there are four key dimensions for horizontal management that revolve around horizontal structures and keep the horizontal structure/movement intact: [*]

  1. Mobilizing team and networks: Ready for action
  2. Developing shared framework: Working for the same goals
  3. Building support structures: To keep Horizontal team in check with Vertical roles
  4. Maintaining momentum: Keep progress moving

Each section would detail a significant amount of content so I will break it up into 4 posts to cover this topic….. eventually.

[*] = Hopkins, M. Coture, C. Moore, E. Canadian Centre for Management Development, 2001. Lessons learnt from Leading Horizontal Projects