Scaling to new Heights

Tags

, , , , , , , , , , , ,

Hello all,

Summer holidays are over and its time for a new post. The focus of today’s post is about Scaling. This subject is on the mind of many people and organizations that want to embark on adopting new processes and practices.

Let us use the climbing of mountains as an analogy to this subject.mountain Like any worthwhile endeavors there are many factors to take into consideration before taking them on. These factors have varying degrees of importance, which are directly linked with your very own organizational context. There is no single magical way to simply apply a formula (i.e. Framework) and expect it to do wonders without getting down into the nitty gritty. If we were to venture on an expedition for a mountain climb, we wouldn’t simply take it head on without context. What would be the preparation required if we were to climb a hill? What if that hill happened to be Mount Everest? We can rapidly assess that our climb and preparation would be different in that case since we have a good visual idea and with a little research we could easily figure out that it is no easy task. In this case, Scaling Scrum or any other processes is the same as moving from our local bunny hill to mount Everest with a distinct difference, it is much more abstract. An organization is a living thing, made up of many layers which are complex (i.e. People), we therefore have to be prepared and have tried our hand at this activity before tackling the holy grail of mountains. On this journey, we are bound to get into trouble and find ourselves with insurmountable chasms or challenges that we could of never foreseen. To the trained and experienced it might all sound so obvious and yet, we can never foresee how the next experience will be like because of the ever changing conditions (i.e. Your organizational contexts). Members of the Teams that are faced with these might or might not be able to tackle on such feats in the short term, so how could we venture forth ? One way might simply be to tread carefully with knowledgeable individuals or teams and see where that leads us.

Assessing your skills and practices is also a good way to get started. As an organization, knowing where one can apply good amounts of work is invaluable in order to gain to most out of your initiatives. Recently, Scrum.org presented Agility Path and it provides that foundation with which you can build on. I invite you to go check it out http://www.scrum.org/agility-path.

Thank you and stay tuned as always,

PS 🙂

Advertisements

Focus, dare I say!! But wait..

Tags

, , , , , , , , , ,

Hi all,

In the few past weeks working with my Teams I still get the very same recurring “problem” when we are a few days in a Sprint. Today’s subject is Focus. Yes. I shall extrapolate what we are looking for when talking about Focus, because it seems like lots of people choose to make it mean something different than what it is, especially when adopting Scrum. Focus is one of the many values of Scrum and is important if a Team is to deliver high value to the LaserGraphic1Product Owner, therefore the organization. Focus in this context is not about losing sight of your surroundings and putting your head down to concentrate on some complex piece of work, though that is exactly what comes from habit with most of the developers. One aspect of what plagues sprint delivery is that Teams lose sight of the value that must come out of it, members get caught up in the work and have difficulty acting as an actual Team. This problem occurs most of the time because of poor work design. The actual work to be accomplished has not been designed for Teams, rather it is put into a series of hands that a single person will take responsability for and hand it over. Another phenomenon that happens is this functionnal “lust” that is created during the sprint where it seems that no one can resist the temptation to start something new before even remotely finishing the agreed upon “Definition of Done”. The argument for the behaviour is that while it seems some of the members are enjoying work on a piece of functionnality, others feel the need to start another in order to get ahead. This illusion of creating great strides into the selected increments of the Product Backlog leaves the Teams exposed to weak integration and low quality all around. We all know where this is leading, if there is poor quality then value has not been attained. As a leader and force of influence, one must work to have members Focus as a Team on a global objective. Making them explicitly aware of what the next steps are to accomplish that goal and for them to set in motion the necessary work to achieve it is where they should excel at. Like all previous subjects I have written about, it always amazes me that after all this time Teams struggle with these concepts. To be clear, the responsability and accountability of the making sure this is understood lies with the Team coach (i.e. Scrum Master). Like many aspects of the efficiency of the Teams organization, the coach is a strong and essential component if an organization wishes to adopt Team processes. Remember that when it comes to focus, be aware of the business objective and always make sure that members don’t dig themselves into holes.

Thank you and scrum on!

Penny saved is a penny earned

Tags

, , , , , ,

Hi all,

Food for your thoughts. I have been exploring with a fair amount of time the subject of Leadership. What is interesting about this subject is that there is plenty written about every possible aspect of this important organizational pillar. For all the different views and tips on how to be a great leader or better yet, how to groom leadership the no. 1 conclusive statement that can be made is this : Fail early, Fail often!!

atlas

Now for those thinking about my Post title and asking themselves what it has to do with all this, I was trying to illustrate that the experiences encountered (saved) is in itself what is necessary for great leadership. By your actions and experiences saved you earn your leadership skills. Let’s be totally clear here. To be an effective leader, a great leader must possess a good amount of the traits necessary for it and also, the skills mustered from hard earn everyday failures! Shout out to Luke for his recent experience, he gets the general idea. Furthermore, the actual skills that I am referring to are none too easy. Striking balance between clarity and incompleteness when setting direction for a department or organization for that matter is not something everyone is capable of. Like great writers such as Richard Hackman and Hirotaka Takeuchi put it, the role of leadership is not one that comes with simple unvirtuous things like a corner office, great pay and running around brandishing a stick to get people to fall in line. It is one that most often than not comes with alot of weight with little room for praise, surrounded by controversy is more likely, just take the recently departed Margaret Thatcher for example.

So remember, while you sit envious of some of your leaders, ask yourself if you have the necessary skills and most importantly the perseverance and patient to garner the weight of as little as a few individuals on your shoulders. Food for thought!

Feel free to share. 🙂

Thank you, PS

UX vs Them Part 2

Tags

, , , , , , , , ,

Hi all,

Time for part 2 of this short series about Graphic and Design work within Software development.

This post revolves around the little progress we’ve made to reach any kind of headway into getting teams to work to produce functional pieces of work. It certainly would seem that way at first glance, but like so many adoption processes we have made leaps in terms of understanding and reflexion on what it is they do to get results. This brings to mind a great story, “The little engine that could”. The general feeling is one of Reluctance. The immediate stare that you get and question that forms behind it is : “What am I going to do if I don’t work on the whole picture?” The prerogative was to work on everything before anyone could get a sense for what was actually needed. i-knew-couldThe UX people would simply hand down the work to the little people (warning* dramatization) and would simply wait in the wings to either argue the points brought forward by developers or have the sudden urge to rework everything having an impact which could be felt all the way to the Product Owner. As you know, talking about this subject in Part 1 we wish to create a Team who can deliver complete (according to Definition of Done established by that very Team) functional pieces of software. As of now, the reluctance is such that all we hear is “No way I can”. In certain members, which is why I said that we have made great progress, we can hear “I think I can”. For you guys out there having achieved a fair level of success, I work towards “I knew you could” :). Obviously, we want them to gain a sense of greater purpose and work with all the diverse fields of competences to achieve great results. What we have seen rise out of certain teams, especially the ones that can’t navigate the remaining work within their plan, is that it realizes that these members with such a narrow field of competence isn’t helpful. They quickly realize that together as a group, have the ability to come up with great ideas and answer the functional needs of the business. This brings us to the last great improvement that I saw rise from these newly formed Teams and this is the ability for them to be critical with themselves about the work they do. Did seems quite ridiculous at first, though I have to remind everyone that before this time Teams were given work and this work was handed out to individuals which would work in their own little bubble. The behaviour comes from the now newly formed identity which is reinforced at every opportunity that they have to work together. They now see fit to be more critical and not simply take things lightly when the work someone around them does impacts the results.

There is alot of work still to be done and I have no doubt they will achieve greats software together like they imagine they could. We are all capable of change, though not everyone is willing to make the effort. At times it is very conflictual, not only with people around us but rather within us.

Thank you and Scrum on! PS

Agility!?!?

Tags

, , , , ,

Hi all,

I feel the need to post something I wrote for our corporate website. These days I have been in the middle of two very different organisations, but they share something in common, they have no idea what being Agile is all about.

http://www.gsoft-group.com/en/blog/organizational-agility

Enjoy and i’m about to publish UX vs Them part 2 very soon.

Thank you, PS

Who are you gonna call!?

Tags

, , , , , , , , , , , , , , ,

Happy Holidays to one and all!!

skill acquisitionNow with the title of this post, I shall answer the question by saying, when we have a problem we call an Expert. We shall explore this in terms of Scrum and it’s adoption. We will use as a backdrop our friend Dreyfus’ model to our left.

The objective here is to shed some light on the problematic that many organizations face when attempting to adopt Agility with people they are not confident can answer the call to properly and smoothly bring them to their goal. One thing is for certain, when starting a new adoption or affecting change for that matter, it is never as pretty as you wish it to be. One reason for any organization to have a dedicated Scrum Master is to ensure that these adoptions go as smoothly as possible. Remember that one of our main objective is to enable Teams and all who would be affected by change to understand why these are taking place by facilitating these new measures. Often times, organizations are not staffed with “Experts” on their Teams and enabling them to master their craft and become better at what is required to turn requirements into pieces of functional software is key to success.

The road to expertise is not a short one and takes effort, a Team effort to realize one’s goals. One of the biggest challenges faced by a team is this need to predict, eliminate all sources of uncertainty as much as possible and quickly. Translation, doing a lot of digging upfront. If we examine Dreyfus’ model, we will see that by acquiring skill we go through phases of pattern recognition and end with simply doing what is necessary, because we know it works. As I have said many times before, Responsability is key in Scrum and when one fails to adhere to it, issues naturally ensue. I like to coin a phrase from Lyssa Atkins in this case which I like to apply to Scrum in regards to responsability and it’s structure which is “Show the system to itself”. Scrum is setup in such a way that all who wish to try to wiggle out of it’s responsability or hide, we will be able to unearth in more ways than one. It is fundamental that all members of the Team feel a sense of responsability beyond the barrier of themselves as we progress and why being (means to be) an Expert is crucial in goal realization. Developing these skills is crucial to unlocking the power of the Team.

So, who are you gonna call?! A great Scrum Master..

Thanks, PS 🙂

UX vs Them (Part 1)

Tags

, , , , , , , , ,

Dear practitioners,

From the very first time that I found myself representing change and implementing new approaches within an organization that found itself in the wrong end of town, most often times by taking too many wrong turns when it comes to software development practices and processes. In the center of it is the mother of issues, Graphic Design.

Oh yes, the obligatory activity that many organization put at the front of the bus and often times let’s it drive. Lets get one thing clear before we talk more about this, Design does not drive function. Function drives not only design, but the very development of the software which gives it value. The one mistake that most departments make is to simply let themselves believe that they require huge amount of time to work eccentric global designs that will make a product revolutionary. They will work at this design with personnel that have no idea of how this can actually translate into functionnal pieces of software.

Recently, a lot of focus has been put in understanding the real cost of technical debt and it’s impact on delivery. What do you figure a design which ends up being X times more difficult to integrate is? If not debt, then it is a big waste of time and money if the very work which is suppose to be integrated along with the function is either too complex to fit or does not align with the very essence of the requirement. One comment, which truly has come up very often, is how do you expect us to get a design done within a Sprint. To my astonishment, alot of people believe that there is no way it can be done. That it is simply theoritical. I get “Well yes, in theory, but you know.. in reality”, since when did we make theoritical software. As you know, this leads to a subject which I have covered many times, change management. For too long, Design people have simply behaved by working ahead and throwing their work over the fence to development teams and go on their merry way. The us vs them mentality has to stop to gain any kind of ground when it comes to be able to integrate design elements within software increments. Teams must be composed of people with the abilities to complement designers. This is part 1 of a series because I will be implementing changes that covers this topic in the very near future and I shall let you know of our progress.

In closing, alot of “ink” has been spilled on this subject and like I have said before, most look for a magical method for what ails them. Remember that no one solution works if it is not an exact match with your context. It would be like doctors giving a prognosis over the web and referring all patients to it. Scrum is a very powerful tool. Use it to learn.

Thanks, PS 🙂

Extra! Extra!

Tags

, , , , , , , , ,

Hi all,

My latest rounds of training being done, I noticed a trend emerging from these sessions. The impending desire for people to be told what to do is imprinted really deeply in all of us. One thing that is fundamental in the course we give is to destabilize to root knowledge of how software development should done. For too many years we have built a notion that software can be, somehow, scalpeled or boxed in order to fit into a well oiled defined process. For those of you who have taken the time to read my previous posts, in most of them I mention the fact that it is important to remember that software requires complex cognitive work, which implies creative work. This work cannot be mapped to a predictive pattern. Scrum works well, if you haven’t guess it yet, because it is rooted in an Empirical process. Empiricism is what leads us to understand something by acknowledging that we must first try something and then adapt to better suit our context. This context, especially in software development, is ever changing and therefore not suited for defined thinking.

It would be like trying to fit the square peg you have on your right into a round hole over and over again. You all know, as well as I do, knowledge is power. Simply applying that knowledge is wasted if not well adapted. This is where Scrum comes in and why it is perfectly suited for our industry.

Now, in order for that to happen we must first be willing to fail, therefore let people work out their own problems (source of motivation) in order to achieve higher efficiency and for people to understand the foundation of why we do certain things (within Scrum). Alot of people have a hard time grasping this fact, mostly because it is so much outside their comfort zone.

Feel free to share your ideas, comments. Scrum on!

Thanks, PS 🙂

Quality: last of line of defense

Tags

, , , , , , , , , ,

Hi all,

Thought I would share with you a growing concern that keeps gnawing at our heels as an industry, the software development industry that is and it’s Quality! (Yes, I talk alot about this, for good reason)

Everytime we start a new development effort or work with clients to build software based solutions it seems that it always comes down to the amount of money it costs to develop. Not only do we talk about how much it will cost, but rather how low can we go to build this piece of software and this is where we fail as an industry or should I say “so called” Professionals. Ultimately, there is no room for argument about what needs to be done in order for organizations to get working software. It drives me nuts that we have to justify our actions in order to achieve best results. We have, for a long time, focused mostly on cost and time. I have been in too many discussions where we expose an issue and are given a ridiculous timetable because the business takes responsability for a feature/function. You should know, if you don’t already, that pressure only drives quality down. This behaviour seems to be part of the very fabric of our being, a natural response to a stimuli that pushes us to get results, but bad ones. This is at the heart of my responsability, a Scrum Master’s responsability to make sure that all parties are aware of the risks, behaviour and patterns that feed this perpetual wheel of Crap. It would seem that alot of people see software as a giant rug where various elements can be simply swept under and forgotten. People will argue, but what defines Quality, well according to business dictionary:

In manufacturing,  a measure of  excellence or a state of being free from defects, deficiencies,  and significant variations,  brought about by the strict and consistent  adherence to measurable and verifiable standards to achieve uniformity  of output that  satisfies specific customer or user requirements.  ISO 8402-1986 standarddefines  quality as “the totality of features  and characteristics  of a product or service  that bears its ability to  satisfy stated or implied needs.”

In other words, Quality is obtained by a fully functionnal feature which in turn gives you (the organization) maximum business value. The point is, Quality is not driven by cost, rather it is the practices utilized in the process. As a profession we recognize certain practices which need to be in place in order to minimize defects, these practices happen to have a cost which should be established as the minimum effort required. Lastly, if you intend on building something and your starting point of view is that Quality is too expensive, why are you building it in the first place. One more thing, Quality is not a coefficient of a function, if you don’t have the appropriate practices you will surely paint yourself in a corner and a single breaking element could mean the feature is used or not at all. If the feature does not provide the intended purpose value is not attained, period. As a development team you should provide a clear message, 100% visibility, with a strong “Definition of Done” and drive it home. Anything less than these will result in loss of Quality and introduce Debt elements or/and more likely, unknown variables.

Sustainability and maintainability is key to any software and is at the heart of Quality practices in software. Never forget that software cost does not end with simply the development phase.

Thank you all,

PS 🙂

Band of Developers

Tags

, , , , , , , , ,

Hi all,

Quite recently, I have been in the process of helping an organization with the adoption of Scrum. Like I wrote in the past, education is at the heart of a sound implementation in order to establish a common base of understanding across all parties. The good word has already started spreading across the people and positive things have started to happen, but I digress. A hurdle that most (if not all) organization face is adapting the roles that already exist within and find ways to express the new responsabilities for individuals that have long been in positions which hinders Agility.

Uncertainty

At the beginning things always seem to look like this (left image). Management is at a loss with roles and responsabilities. They find themselves wondering “What happens with project managers? Who will make sure people have things to do? Who will keep everything on track?”. They are also left with not knowing what they (Management) will be doing in all this. This is where when I started doing this, I got baffled at how people who were suppose to be leading a company, making it the best it can be suddenly seem like they have their pants down and have no clue on how or what they will be doing. I believe the answer is so self evident that they can’t seem to see it. I like to tell people that one obvious responsability of a Scrum Master is to point out the “Elephant in the room” and have to say that I am quite happy at doing it. Like the many posts I have written before this one, we have to establish clear lines of responsability and let the people who have the competence to be accountable for their actions. Developers will learn to work together and form a team. As Scrum Masters we have to enable them to make that happen, meaning that roles within the organization cannot hinder this in any way otherwise developers will fall back to finding ways to wiggle out of decision by letting non-expert individuals take it for them. There is nothing like adversity and conflict to bring people together. Organizations have to learn to let people fail in order to learn. It is how Scrum Masters do their magic, by being patient. It is only through knowing that something is valuable that people will continually do something.

Be assured, with the proper amount of discipline, work, perseverance, determination, leadership you will get to this point (image right) without any hesitation. Lastly, remember that motivation stems from the activity of mastering ones abilities, sense of contribution and purpose.

Thank you …

PS