Well, I'm back to bring you an awesome video of Mary Poppendieck. From that video I got the inspiration to write the previous article.

A little background information about her would come in handy here:

Mary Poppendieck has been in the information technology industry for 25 years. She has managed solutions for companies in several disciplines, including supply chain management, manufacturing systems, and digital media. As a seasoned leader in both operations and new product development, she provides a business perspective to software development problems.
Lean development is just one of Ms. Poppendieck's areas of expertise. She first encountered the Toyota Production System, which later became known as Lean Production, as Information Systems Manager in a video tape manufacturing plant. She implemented one of the first just-in-time systems in 3M, resulting in dramatic improvements in the plant's performance. Ms. Poppendieck's team leadership skills are legendary at 3M, where new product development is a core competency. One team commercialized a graphics interface controller three times faster than normal. Another team not only developed an image database system in partnership with a start-up company, but also set a new international standard for image formats. Poppendieck, a popular writer and speaker, is the author of Lean Software Development: An Agile Toolkit and Managing Director of AgileAlliance.

 And the video. It's a MUST WATCH for any leader in the software development business.

'morning folks!

The entire week I ruminated about what should I write this weekend. I almost began a blog post about some neat group management techniques that may come in handy when we are talking about the SysAdmin way of working, an agile way to improve efficiency and productivity on an area which focus is mainly on putting out fires. But I won't be ranting about that (maybe next week). Instead, I'll try to express some thoughts that come from experience and personal learning, about how leadership should be in an agile environment.

Let's go back in time about 100 years, in order to remember some things about work management a nice north-american fellow said:

   - Workers are lazy, they will always do as little as possible.
   - Workers do not care about quality
   - Workers are not smart enough to know the best way to do they job.

That, in a nutshell, is what Taylor said at the time about which was the best way to manage the workforce.

The Spanish Theory of Value is alive and well among managers everywhere. You see that whenever they talk about productivity. Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.
That's not exactly productivity—it's more like fraud—but it's the state of the art for many [...] managers. They bully and cajole their people into long hours. They impress upon them how important the delivery date is (even though it may be totally arbitrary; the world isn't going to stop just because a project completes a month late). They trick them into accepting hopelessly tight schedules, shame them into sacrificing any and all to meet the deadline, and do anything to get them to work longer and harder.

So, we pretty much nailed down the kind of managers we are talking about.

How does all of this relate with the Agile Methodology? Well, as the English Theory of Value states, through technology and ingenuity, productivity can be boosted. In this case, the ingenuity of time-management, project management, and above all of this, giving people respect for their work.

All of this should be easy to implement and do in a working environment, but sometimes it is not. Lets remember *always* that we are talking about people, and that people must be prepared to take this philosophy to the full extent of it. Otherway, it won't work.

How should an agile team leader be, and what should he do, in order to better do his job? I think he should:

- First of all, know a lot about the agile methodology. It doesn't end with stand-ups.

- Be able to say "no" to the product owner, if he believes that the amount of work the PO is taking from the backlog into the monthly or weekly iteration is not achievable or unreasonable.

- Know the people he is in charge of. Their skills, motivations, way of working, hell.. even hobbies. The employees must be able to trust him and take him as a reference, he must know what people can and can't do, and devise new ways to bring them up to the challenge.

- If somehow an employee fails to do his job, investigate to the full extent what were the causes of this. Perhaps some guy was left by his wife and has not been able to sleep in a month because of depression, or has family issues, or just can't stand their coworkers because they had an argument or a fight. If the leader is not trusted, people won't open up to him. He won't be able to lead anything, merely to do some clerk work.

- Bring ideas and new ways of working to the team, so things that should be done in a better way will be. And listen to people that give him proposals. Remember, what an agile leader should value the most is the people.

- Protect the team. If his role is to be the leader of a team, he should protect it and nurture it in a way that the people that's in that team really *wants* to be there, not just because they get paid a lot of money. Just giving people more money is *not* the solution. Create a good environment, bring some perks to the office so that employees feel happier. Organize dinners, make people mingle so that when they have to work together, all of the roughness that could be there is wiped away, then they trust each other and know the person that is their daily wingman. We're talking about a team, not just some workers thrown together.


There is certainly more that should be put on that list, but those are the basics. It's Leadership 101. If you have a team leader that:

- Says "yes" to everything the product owner asks, and then puts pressure on the team so they work unpaid overtime in order to be able to make it before the deadline.

- Does his job the way he knows, but never bothers to find out how to do it in a better way, or is not genuinely interested in learning more in order to be the best proffesional he could be.

- When the product owner puts pressure on him, he only knows to turn and put that same pressure on the team.

- Doesn't think of any ideas so that productivity gets boosted.

- Doesn't really care for the teamworkers.

You don't have a leader. You have a problem.

'Morning! (or whatever form of salute that suits better your time zone)

Today I'll be blogging about my thoughts and quite brief experience to this day as a developer who is learning whatever is needed, in order to become a systems administrator ambassador, and I'll do this in an attempt to better understand what this role entails, and to try to describe to you why is this middle-man position is so much needed in the world of software development today.

At present day, I work for vLex, an online legal information platform. This enterprise is located at Barcelona, Spain, and it's been growing since its birth back in 1998 (this I read from their page, I've only been working there for 3 years now), but I believe that the growing curve has taken a steep step since an argentinean IT team was formed about 6 or maybe 7 years ago.

This team, of which I'm part of, consists now of seven persons, and works closely with a smaller team in Spain in order to improve and maintain the platform, solving the needs of the clients and learning whatever technology is required along the way. A part of the team in Spain consists of the much scorned but needed systems administrators. Those kind of employees you've probably heard being characterized regularly as practical nazis (even from a professor at my university) because of their jealousy when it comes to managing the IT infrastructure of the company, with regard to the developers that use that infrastructure in order to add value and build the product that the enterprise is trying to sell. If you've ever read any of The Daily WTF articles that have anecdotes about the adventures of IT workers around the world, there seems to be an infinite source of short sightedness in this kind of fellows.

Nevertheless (and before my colleagues from spain kick me out of the sysadmin team if they ever read this), their job is clearly a must have at any enterprise that needs to maintain an IT infrastructure in order to provide a layer of service to any other part of their staff. From the developers that use that infrastructure to maintain and develop new software, up to the management layer, and back to the sales team that engage in.. well, sales. The productivity of those other parts of the enterprise sinks (if it doesn't completely cease to be) when they have to deal directly with the intricacies and gears underlying the tasks that they've been hired to perform.

On the other hand, and perhaps so we can balance this out, we as developers have certain vices that don't come easy when we are talking about taking care of that infrastructure we so much need, so the labour of the team that keeps the circus running in the background is easier, or at least not so much a pain in the arse. From security measures we never bother to take, to shortsightedness when it comes to assesing the resources, profiling our creations, and measuring the impact we could have in order to safely execute a program we just developed so that it won't tear down the entire system and ruin the party for everyone. We also sometimes do our fair share of the mistakes.

In summary.. come on, let's admit it, we need that layer of technicians so they can save our butts when somethings falls apart (being this a webserver, an oracle database, or anything else that requires some level of specialization and experience in order to get it working smoothly), because even if we developers could work our way around to solve the issue at hand, we may also break something else because the mentality of a developer is not the same of as that of a sysadmin. The sysadmin is more concerned with security and performance of the system, whether the developer seems to lean more to "let's just get this thing working so we can get back to coding".

Perhaps all of this, combined with the distance that comes when there's a team working for you overseas, brings a storm of lack of communication that pretty much difficults the work for both sides of the pond. For the last two years of work I've been a witness to all kind of misunderstandings that provoke friction, animosity and distrust between members of both parties. It's not easy to overcome this, and I believe that productivity has been sometimes hindered because of those events.

This year a different approach has been brought to life from the upper layers of management that kind of address this issue. Some practices of the Scrum agile methodology are being followed, and I've been appointed as "Systems Ambassador", a position that didn't exist previously. My job is to specifically address the issues that concern both the sysadmin team and the development one, as well as having a view of the entire picture, something that up to this day only the C.T.O. had.

Extracted from my job description:

- Help in the transference of essencial information between the Sysadmin and Dev teams, at stand-up meetings.
- Maintain the local development environment of the argentinean dev team running smoothly.
- Lead on the research of new technologies regarding systems architectures, write improvement proposals, develop new pilot projects on them.
- Gain trust from both sides, but mostly from the Sysadmins through a careful administration of the tasks at hand related to that specific area.

This last point is related mainly to politics and the issue I've been ranting previosly about: smoothing all the roads that come and go between people that have different scopes, and improving the communication among them. It entails being "politically correct", and also able to perform nicely on both sides, as a developer, and as a sysadmin. It involves some kind of interdisciplinary art, although we are only talking about IT. It also involves getting in touch with the people behind the proffesional, so whenever shit hits the fan, we will have the necessary trust in the work that our colleague is doing and not start blaming each other.

In addition to all of this, there's another aspect that has come to life recently with the new tools that a Sysadmin needs in order to maintain and report the status of the systems, and focus on the big picture instead of being consumed by petty tasks. I'm talking about administration tools like Chef or Puppet.

This tools provide a framework that puts up a layer of abstraction between the sysadmin and the system itself, and they do it by giving the administrator an API where he can code his needs. There's a real need to think as a developer in order to be able to do this, so in the long term there must also be some kind of transformation of the Sysadmin mentality towards the Developer one, just as my job is to take the road on the other way.

I haven't had any experience yet with those tools, but from what I read, there's more to them of programming language than of the old configuration files, so they should be treated the same way we treat we treat our source code: with repositories and versioning systems. And they are a must now as the infrastructure keeps on growing and growing, and the team is overwhelmed with all kind of incidences and troubles that arise on an everyday basis. We need to see the big picture and manage it accordingly.

In the end, the line between our worlds is getting blurried, and that implies that there'll be more learning to do and communication skills to shape up. But this ambassador stuff not only applies in this kind of scenarios between two teams that do different kind of work. It's a must whenever there are groups of people that need to work together and there's a big gap between, be that 1000 kmts, or just that they work on different perspectives of the same problem. We must improve our communication skills, precisely because we don't want to, and have always been more comfortable dealing with a computer than with a human being.

I'll be blogging about my experiences this year on this subject, but also on other stuff... at random, but always about IT, so I stay on topic with the name of the blog.

Hope you learned something from reading this! :-)