Architecture [Jane Divinski]

It’s essential to have good architecture for a software product; it’s also key to architect appropriately the engineering group.

You might think that the ideal team is a group of very experienced software engineers. Yes, in the early days of a startup this can be the optimal team. However, after the initial proof of concept period it’s actually preferable to have a varying amount of depth in the group. For a while the senior folks will gladly do each and every mundane task along with the exciting, challenging ones but at some point the thrill is gone. Handing off such tasks to less experienced engineers makes good sense for a variety of reasons, including cost.

Depending on the type of software product being developed it may be necessary to have engineers with practical operational experience as well as those who have exclusively focused on product development. This is particularly relevant for large web applications. How much interaction will the development team have with other functional groups? Again, depending on the type of product under development you might find that only a subset of the software team works closely with other groups. Other times it’s essential that each developer be capable of communicating frequently and clearly with people in product management or manufacturing or even directly with customers.

One concise definition of architecture is “the way components fit together.” An engineering VP wouldn’t leave it to luck to have a decent software architecture; likewise it’s good to have at least a mental rough draft of what the ideal people infrastructure should be. In both cases, whether architecting a product or a group, ongoing adjustments will fine-tune the original plan.

___________________________

Jane Divinski, Engineering Management Consultant since 1994
http://www.jadski.com

More...

When impediments dominate [John Levy]

Agile managers are supposed to be "servant leaders" and to spend a good deal of their time removing impediments to effective work by the team. What happens when the impediments you're trying to remove are so big that (a) the team is working at half efficiency at best, and (b) removing the impediments requires intervention up the management ladder at least 2 or 3 levels?For example, an enterprise I know about has barriers to efficient work that have to do with software environments and bureaucratic procedures for deployment of releases. A manager at the VP level has reported that when a funding request to fix the environments comes up, it gets knocked out by the financial folks "because it won't increase revenue." Meanwhile, releases take an extra week or two because approvals have to travel up a 3-link chain, the last two of whom are not in fact concerned with (or knowledgeable about) the particulars of the intended release.

It's easy to get frustrated with such impediments. As one of the technical staff said recently, it's a case of "I love the work and hate the company." Not that the place of employment is unpleasant -- on the contrary, it's a very supportive and friendly physical place to work, at least on the surface. But the ossified bureaucracy indicates that something about the enterprise is extremely un-Agile.

Within this context, however, there are positive indicators: a significant number of bright, capable and "agile" people who recognize what should be done; strategic initiatives coming from the top that seem well-focused; and a willingness to bring in new ideas -- and consultants. This sets up an interesting tension between the "let's get the transformation done and move on" people and the "we have to follow the rules and processes that have worked for us for so long" people. Even this statement is not entirely fair: the "rules and processes" people are doing what needs to be done to satisfy the financial processes that make the place run, even as they know that something has to change. So the challenge is to establish ways to evolve the processes into something more agile.

Can an agile software consultant do that? Probably not. But the consultant can do a number of useful things. One is to encourage teams to operate in an agile way, while finding practical ways to feed the needed numbers into the financial gear-works. Another is to provide unbiased information from grass-roots teams to key change agents (managers who are moving the enterprise in the Agile direction). And finally, a consultant can advise the decision-makers when old processes are just too creaky to keep as the enterprise moves into the 21st century competitive world.

Of course, you may be able to do all of these things from within the enterprise, too. Be the consultant and change agent; but be sure you have the support of your network of other change agents -- you may need it to keep your job.

_______________________________________
John Levy consults on Agile development and is an expert witness in computer & software patent cases. He has 30 years’ experience as a technology manager at Quantum, Apple, Tandem and DEC. His book on managing technology, Get Out of the Way, is due out in 2009. Check him out at http://johnlevyconsulting.com

More...

Out of Sight of Land [Courtney Behm]

A former Business School classmate of mine, Rich Wilson, is an avid, and some might say slightly mad, sailor who has used his love of the sea as the foundation of a non-profit organization called sitesALIVE (http://www.sitesalive.com) that provides K-12 learning adventures. He is currently more than half way through a solo around-the-world race called the Vendee Globe, which requires participants to sail through unthinkably rough and stormy seas without receiving any more assistance than advice and counsel. He can’t dock anywhere to do repairs, can’t let anyone on the boat, or accept any deliveries. The vagaries of the sea, the unknown dangers, the weather reports that say 20 knots of wind when Nature is serving up 40-50 knots, all conspire to create an environment that, despite all his training and experience, consistently presents unexpected challenges to his ingenuity and survival instinct.

I’m following his progress daily, as Rich is a good friend, but I’m also reading about the other sailors, marveling at miraculous rescues at sea, shaking my head at the disasters that strike swiftly both the leaders and the back of the pack. But more than anything, I am awed by the courage, as well as mystified by the willingness, of this small band of men and women to take to the sea alone in small boats, committed to remaining out of sight of land, except at a great distance, for more than 3 months.

Last night, as I was reading Rich’s latest log entry, it occurred to me that lately we are all losing sight of land. Since the dot com bust, we have been shaken, stirred, dropped, kicked, elevated, depressed, celebrated, vilified…and just when we thought it was time to put into port and rest, our boat turned turtle, or we fell in the companionway and fractured a rib, or our rudder snapped off, or our mast toppled over into the water and there we were, in the middle of the ocean, with no obvious way to get back home in one piece.

It’s a tough time – probably not as bad as the papers say or as good as we would like it to be, most likely somewhere in the middle. But regardless, all our assumptions have been challenged once again. How do we remain effective in a time when all bets are off? When a great company with a great product and a great future finds itself in the midst of layoffs and salary cuts and hiring freezes? When the startup funding dries up? When the solid, established financial institutions are gulping and gasping? When our mortgages and our retirement accounts are at risk? Times like these try not only our souls, but our courage, our initiative, and our ability to roll with the waves and stay in the boat.

In an eerie coincidence, as I was working on the first draft of this blog entry, a colleague came into my office to discuss some changes that required us to reset our expectations. He said, “The trouble is, we are trying to deal with something we’ve never encountered before, and there aren’t any markers. How do we forecast? How do we predict? It’s like sailing in a fog.”

In Silicon Valley, technology is the wind that moves the boat forward. And, for the most part, the technology is sound. But technology can’t save us from the unexpected, so we are called on to stay awake, to pay attention, to be in the moment, to take nothing for granted. We need to be grounded, but not rigid, and to keep creating ways to sustain effectiveness in the face of difficulty. We may be managers, team members, individual contributors or consultants, but we are all called upon to be leaders. When the boat is out of sight of land, or the fog rolls in, it will be our ability to stay flexible, and to reinvent ourselves as circumstances change that will put us back on solid ground.

(Information on Rich Wilson’s Vendee Globe progress can be found at http://vg.sitesalive.com. The Vendee Globe main site is http://www.vendeeglobe.org/en)

_________________________________
Author: Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.

More...

Can We All Get Along (Must We?) [Jane Divinski]

Generally I believe that engineering management folks look to hire the strongest candidate in terms of relevant technical knowledge, basic intelligence and work ethic. Another factor usually considered is personality or style, as in communications style. Years ago, during a philosophical (aka “over drinks” ) chat with another colleague who also headed up an engineering team I learned that he considered it essential to make sure new members of his team “fit in”, personality wise. I view this as “nice-to-have” rather than a requirement when hiring an engineer.

I want individuals to be solid contributors on their own but sometimes the best or most expeditious way to make a technical decision is to interactively discuss the issue. The best teams I’ve managed involved smart people who challenged each other so that group brainstorming about a technical approach or even root cause analysis was productive. I DO think it’s important to establish basic ground rules so that anyone with a relevant idea can get their voice heard, whether he/she be very outgoing or somewhat shy in nature. Some of the best technical discussions involve heated differences of opinion but it’s usually possible to analyze the various approaches being championed and determine together which makes the most sense given the existing constraints and unfortunately, there are always constraints :) .

We often hear of company culture; individual groups within the company have a sub-culture that may be different from the overall corporate philosophy. For example, I joined one small software company as interim VPE and was really surprised at the communication style within Engineering. There was nothing unusual about the cross functional communications between groups. Within Engineering, however, there was a pervasive need for all discussions and emails to be measured and thorough and extremely polite in tone. This itself is not an issue but I noticed that ever since the company had relocated to the Bay area (bringing the core engineering team with it) there seemed to be an issue in adding people to the team. Three engineering hires in a row “did not work out.”

Once I realized that the core team of this small engineering group had joined the company together when the professor for whom they all worked as graduate students founded the company I better understood the dynamics. It became clear that part of the problem was that the new people didn’t understand the “rules of engagement.” During the several months I was part of this team I worked to change the focus of the group discussions so that the emphasis was on the quality of the technical opinions expressed rather than on how politely the ideas were communicated.

I believe that it is healthy AND often extremely productive to foster unstructured brainstorming even if it involves disagreement. Ideally the members of the team will feed off each other’s energy and creativity; sometimes the best result comes from iteratively slicing and dicing one proposed approach rather than just completely accepting or rejecting each proposal in its entirety.

How much importance do YOU give to building an engineering team whose personalities mesh as opposed to establishing an environment of constructive disagreement?

_______________________________________
Jane Divinski - Principal, JAD Consulting (Software Engineering Management Consulting since 1994) www.jadski.com

More...

Can you manage conflict in an Agile way? [John Levy]

A company I know initiated an agile software development project in 2007 using Scrum. They put together a very competent crew of developers, isolated them in a corner of the building, put them under a manager who understands and is an advocate for Agile frameworks, and let them start. There was only one hitch -- their business counterparts were 750 miles away. Nonetheless, the team overcame this obstacle by daily telephone conferences, online file sharing, and frequent visits by the business folks to the developers' location. Development continues with frequent demonstrations of working software.

This year, a larger, existing group of developers and website design people in the same company decided that all their problems could be solved by going Agile. The list of obstacles, however, is quite a bit longer:

1. The development managers and some of the developers are also 750 miles away from business and website design people.
2. Some of the developers and QA people are contractors at a location a few miles from the development location.
3. Other developers are offshore -- in India.
4. None of the developers or managers have experience with Agile / Scrum teams.
5. The development work is dependent on a number of vendors' software packages.
6. The physical work area at the company's plant is not conducive to Scrum team interactions.

This may seem like a lot to overcome. In fact, it may look like a fool's journey to take on implementation of Scrum in this environment.

But we're still not through the whole story. Here are a few more issues:

7. The server software environments for development and for QA are not the same as in the operational systems.
8. The QA people are constrained by company rules from accessing the live, operational system.
9. Attempts to allocate budget for infrastructure improvements are consistently thwarted "because they won't increase business."
10. Frustration at the low throughput of finished projects has led to a lot of conflict between the business people and the development people.

So now let's consider a few questions about what to do if you're an advocate of "Agile Management" ....

Would you take on the Scrum training for this company? If so, would you expect the company to see positive results within a year?

Where would you begin to tackle the productivity problems at this company?

If the CIO asks you what should be done to make development run more smoothly and more productively, what would you say?

And finally, how would you justify (to the management) spending dollars on infrastructure improvements?

Yes, I am involved with this company, and for now I'll tell you only that I'm addressing issue number 10 first -- the conflict between the business people and the developers. I believe that establishing a basis for cooperation between people who need to work together is always the first order of business. Is this "Agile Management?" Yes, of course. The top priority is what's most important and most valuable; and getting conflicts resolved is at the top of my list of value-producers.

______________________________________________
John Levy, PhD http://johnlevyconsulting.com
Managing product development for speed and innovation

More...

Who am I, and Why Should I Care? [Courtney Behm]

Theories of leadership. Business School. Seminars. Books. We are not lacking in information about how to be a good leader. But if that is true, why is effective leadership such a rare commodity? Humor me for a moment, and start counting the people you have worked with or for that you would classify as great leaders. I will make you a bet you will not need all of your 10 fingers. So why, if we know so much, and we’re so smart, aren’t we better at this leadership thing? Consider the possibility that we have overlooked one of the most significant markers of effective leadership: knowing yourself really, really well.

Self-awareness gives you a leadership edge? Yep, sure does. But the self-awareness I’m talking about is much more than “me generation” navel gazing. It’s the willingness to take a hard, clear look at oneself in order to answer some essential questions: What are my strengths? My weaknesses? What frightens me? Angers me? Grieves me? What do I hold in highest esteem? What are my values? My dreams? My aspirations? What am I willing to do to be successful? Do I like myself? Am I willing to be real with colleagues, friends and family? What is my leadership style? Am I directive or collaborative? Strategic or tactical? Superb in a crisis, or gifted at maintaining balance?

These are some of the questions that help us find our leadership foundation, but far too few of us take the time to ask them, or to consider that our authentic selfhood is integrally linked to how – and how well -- we lead. In addition, it’s sometimes hard to accept that there are many successful leadership styles, or that sometimes the same person may be called on to lead in very different ways. When I spent several years in between corporate roles as an executive coach, many of my clients were facing the challenge of modifying their formerly effective style to fit a new organizational culture. We had to dig beneath all they knew about leadership as a theory to find that essential self they hadn’t really spent much time thinking about or working with. Caught up in the day-to-day challenges, and believing that there was only one way to be successful, they had locked themselves into a one-trick-pony strategy, and needed new responses to their new challenges in order to get back in the game.

Leadership is not a cookie-cutter proposition. Though there are basic principles that remain constant, leadership styles are as unique and different from one another as the human beings who carry them. I count among my list of effective leaders a gentle, soft-spoken introvert and a wildly energetic, take-that-hill extrovert. They have each had their struggles to find the right match between their style and the organization, but they have both thrived within their leadership roles. The most successful leaders remain congruent to their underlying authentic self, and they map that self judiciously to the culture and expectations of their situation. We can learn a valuable lesson from them…knowing ourselves really, really well will not only transform our leadership effectiveness, but also bring new vitality into the organizations we lead.

______________________________________________
Courtney Behm, MA, MBA
Senior Program Manager, i365, A Seagate Company

More...

What is Agile Management? [John Levy]

We're not into managers who do yoga. But there are two other ways to think of Agile Management.

1. If you're in software development, then you are surrounded by (if not submerged in) people practicing Scrum, XP, RUP or one of the other frameworks for Agile Software Development, so you can find a community of like-minded developers. How does management fit into the picture?The Agile Manifesto http://www.agilemanifesto.org says we value people and interactions over processes and tools.

So the first way of thinking about Agile Management is: we are figuring out how to apply the Agile principles to actually managing a collection of software development teams. This immediately brings up a dilemma. Agile principles emerged from a bottom-up approach which says to management, " We are developers, we can manage ourselves if you let us, the job of our manager is to defend the team and the team's working space. Go and remove impediments. Stay out of our way."
But what about the manager? How does the manager role get filled and the person in the role get fulfilled? Is she a former developer who sacrificed herself to become a full-time non-developer? Or a project manager who now has to learn how to let go of control? Or even a founding software guru who is now running the whole company?

I believe we're interested in all of these questions. And we want practical tips on dealing with real-world problems that come along with an Agile development.

2. If you've been a manager (or Director, or VP) for a while, you have probably discovered that many people regard management as an honorable profession. Americans have been good at more than firmware and pizza (à la Snow Crash) -- they've led in modern management as well.

So the second way of thinking about Agile Management is: how can we apply the principles of the Agile Manifesto to general management? Customer Collaboration and Responding to Change sound like good principles across the board. Can we develop a set of guidelines for managers that establish a more agile approach to the broad challenges of management? Is there something like Iterative Management (something like The One-Minute Manager)? A way of managing that feels as responsive and adaptive as Scrum?

I invite you to join in this discussion wherever it goes.

______________________________________________
John Levy, PhD http://johnlevyconsulting.com
Managing product development for speed and innovation

More...