"project management" entries
Can education and peer review keep a huge open source project on track?
When does a software project grow to the point where one must explicitly think about governance? The term “governance” is stiff and gawky, but doing it well can carry a project through many a storm. Over the past couple years, the crucial OpenStack project has struggled with governance at least as much as with the technical and organizational issues of coordinating inputs from thousands of individuals and many companies.
A major milestone was the creation of the OpenStack Foundation, which I reported on in 2011. This event successfully started the participants’ engagement with the governance question, but it by no means resolved it. This past Monday, I attended some of the Open Cloud Day at O’Reilly’s Open Source convention, and talked to a lot of people working for or alongside the OpenStack Foundation about getting contributors to work together successfully in an open community. Read more…
A common vision is more important than seeking approval
Bruce Eckel is well known for his books in the field of programming, such as Thinking in Java, Thinking in C++, and Atomic Scala as well as his co-leadership of the Java Posse. And yet, on top of his work in programming, he has spent the last several years investing in and researching a topic that seems quite different, yet is intertwined with the destiny of software companies: the culture and operation of businesses.
In his OSCON 2013 Mainstage session, Bruce lays the foundation of modern business management, including a look back as far as Taylorism, a survey of what it means to get an MBA, and ways to gain this knowledge outside of the traditional institutions.
Business analytics projects: Using decisions as a basis to prioritize and identify requirements
Most normal people don’t look at data sets just for fun. They study views of the data to make decisions about what to do, be it a decision to take some specific action or a decision to do nothing at all. The main purpose of business analytics projects is to develop systems that turn large and often highly complex data sets into meaningful information from which decisions can be made.
The decisions that people make using business analytics systems can be strategic, operational, or tactical. For example, an executive might look at his sales team’s global performance dashboard to decide who to promote (tactical), which products need different marketing strategies (operational), or which products to target by markets (strategic). Generally speaking, all software systems that include an analytics component should enable users to make decisions that improve organizational performance in some dimension.
Other than marry Carol Brady, that is...
When computers were small and programs short, writing programs for them was pretty much a solo enterprise. But as computers became more powerful, and importantly, interconnected, you started to see software development in teams, and with teams came the most unfortunate of byproducts, management.
In a modern software development project, there are in fact a lot of contributors who have nothing to do with actually generating code. You have a product owner, determining exactly what functions the software should enable. You may have user experience designers, who are turning those requirements into a cohesive and logical look and feel. You have UI designers, creating graphical assets and fleshing out the U/X designers. There are strictly overhead roles such as managers of different flavors (including scrum-masters, who are really just a specific breed of manager). There are the developers themselves, who may include team leads. And then there are the folks with the mysterious title of Architect. But just what do they do?
In my depressingly long career as a software engineer (the career isn’t depressing; the length of it is), I have seen no title as subject to variable interpretation as Architect. I’ve seen architects that were essentially the MVPs of the project, and I’ve seen ones that are speed-bumps on the road of life. Why they are placed onto projects, and how they are used, can drastically influence the overall happiness and productivity of a team.
Let’s begin our look at the role of architects with the most negative example. There exists a class of companies that have architects Because They’re Supposed To. In this kind of environment, architects can gum up the works in a number of ways. First, these tend to be the people who Read Things in Magazines (or online). They tend to be in love with concepts like elegance and abstraction (which are good in moderation), and to some extent try to justify their existence by making things more complex. They rarely code.
Let’s call this subspecies of architect the Formalists. You can tell them by the fact that they have more books on UML and Patterns on their bookshelves than on languages and operating systems. The Formalists believe in form over function. As an example of the kind of poison they can spread in a project, I once had an architect explaining to me that my clean, compact and well-tested Java code was unacceptable, because I did not implement a single Pattern in it. I added a Singleton (which neither helped nor hurt the code), and he became happy.
The Formalist frequently kills the enthusiasm of the developers with mandates that drastically increase the workload of the developer for little to no benefit. Formalists are the polar opposites of the agile process, because they will insist on building in levels of complexity far in advance of a proven need for the extensibility provided. If you have a simple application laden with Enterprise Service Buses and Factories, a Formalist probably had their hand in the design.
Let me be clear, when used correctly, architects are awesome. Let’s label the group of good architects the Pragmatists. The primary phenotype of a good architect is that they know how to code, and code well. Beyond that, a good architect serves a crucial role in the definition of the product requirements, not just drawing boxes at 30,000 feet.
To understand this role, you have to look at the lifecycle of a successful product. After the basic product requirements have been laid out, but before developers start to implement, there’s an important step that many teams miss. Someone, and by someone I mean a good architect, needs to flesh out the requirements into a sufficiently detailed set of high-level tasks. It is in vogue these days to do this during the “grooming” portion of the scrum process, but it really needs to happen much earlier, and by someone looking at the entire product and how this particular task fits into the overall picture. The architect needs to answer questions such as:
- Do the U/X, UI, and development requirements really cover the end user requirements (i.e., gap analysis)?
- Is this task being designed and developed in a consistent fashion to the remainder of the application (and, where appropriate, the way software is developed at the company in general)?
- Is the design flexible enough to allow future enhancements?
- Does the application implement appropriate levels of security and meet required performance standards?
Considering the "two pizza" team
One of the most common questions I get about applying lean ideas to product design and development is, “How can I make this happen in my organization?” Between entrenched corporate silos and existing team management structures, it can seem impossible for these ideas to take root in large companies. Over the course of a series of blog posts, I thought I’d share a few tactics I’ve used and have seen work with other teams to help get you started. In this first post in the series, I’d like to talk about how to structure your teams.
As much as who you hire, structuring your teams effectively is key to a lean team’s success. Many companies see the individual disciplines in their product development organization as service providers—internal agencies. The business reaches out to these agencies (engineering, UX/design, product management, et al.), expresses a need for staffing and the discipline lead provides the resources based on expertise, availability, and project fit. It sounds like a reasonable and efficient way to staff a project and to that extent it is—however, our goal should not be to simply staff a project but to build a team.
When building your team, focus on the following four criteria to maximize their chances for success:
Keeping your team small means everyone on the team knows each other—on a first name basis. It’s easier to manage a small team. It’s simpler for the team members to know who to go to when they need something specific. It’s easier to keep track of work accomplished and work left to do.
Dani Nordin on what you need to know
We sat down recently to catch up on her current projects and her predictions for the future of Drupal design. She shared some best practices for designing, her experiences with a large-scale academic project, and what criteria goes into the Design 4 Drupal Boston event.
Highlights from the conversation include:
- Learn the common pitfalls Drupal designers fall into, along with some tips and tricks to avoid them (hint: Drupal is like a cake recipe) [Discussed at the 0:17 mark].
- How the Berklee College of Music is using Drupal [Discussed at the 5:49 mark].
- The focus for 2013’s Design 4 Drupal Boston [Discussed at the 7:50 mark].
- The ways Drupal 8 could change how designers work [Discussed at the 9:40 mark].
You can view the entire interview in the following video.
Learn to be a better programmer by taking charge of your interests
If you want to be a better programmer, a good first step would be to choose an area of software development to take additional responsibility for. Now, when we say “responsibility,” we don’t mean the sort of “you’re to blame and you accept it” responsibility that is so commonly thought of. Instead, we mean the willingness to take charge or the willingness to do something about an area.
So select out some area of software development, and decide to be a bit more responsible for it than one was before. The “area” could be simply some additional part of the current project you work on, the whole project itself, some type of software development that you haven’t done before, some aspect of software development you’d like to know more about, etc. If you’re feeling adventurous, try deciding that you’re personally responsible for the quality of the entire software project you’re working on. If you do, you may be surprised at how much easier this makes your life. When you’re trying to maintain the quality of only a piece of a software project, it’s very difficult. You’re surrounded by complexity or confusion, and you have to fend it off at every turn. But when you look at the project as a whole instead and try to decide what should be done with it as a whole, the solution presents itself much more readily. Now, it may seem like quite a bit more work to resolve the problems of the whole project, and it is. But it’s considerably more satisfying, tremendously more effective, and will bring you up to seniority as a software developer much more quickly than just trying to solve the problems of your one particular area.
An interview with Shipping Greatness author Chris Vander Mey.
Chris Vander Mey, CEO of Scaled Recognition, and author of a new O’Reilly book, Shipping Greatness, lays out in this video some of the deep lessons he learned during his years working on some very high-impact and high-priority projects at Google and Amazon.
Chris takes a very expansive view of project management, stressing the crucial decisions and attitudes that leaders need to take at every stage from the team’s initial mission statement through the design, coding, and testing to the ultimate launch. By merging technical, organizational, and cultural issues, he unravels some of the magic that makes projects successful.