The Role of ScrumMaster / Software Development Lead / Manager

Remove impediments, improve the process. Understand what's being added to the backlog. Understand what kinds of "shortcuts" or workarounds are being taken by the team. Understand the consequences and better solutions to these items.

Plan for the next big problem

The stuff you're doing now will likely amount to something bigger and better once you're done. Keep doing what you're doing and getting better at it but keep in mind that there are consequences of what you are creating. Prepare for the consequences and get ready to tackle the next big problem they create when you get there; but only then.

Make the development process be THE KEY PROCESS

Development speed and efficiency might matter more than anything else. Yes, customer requirement and needs are paramount in general, but sometimes they are unclear and the development team can produce something really good that isn't EXACTLY what was corrected. This discrepancy is fine. If the development team can produce Product X which CLOSELY RESEMBLES the 'perfect product' described by the customer, then that is the product that should be produced. Future iterations can make it perfectly align.

Efficient workflow tradeoffs and cost

Workflow can be seen in two ways: that of the SYSTEM USER and that of the DEVELOPMENT TEAM. The end goal for most projects is to create a "perfect and efficient" workflow for the user. Being efficient may involve trade-offs as there is a cost for realizing perfect workflow. If the development team isn't paid for the realization of every incremental user workflow bit, then there is a problem.

Use the skills you have now to add as much value as you can now

Don't get bogged down doing a bunch of boring repetitive stuff now unless it is required. Follow the Pareto Principle http://en.wikipedia.org/wiki/Pareto_principle and knock out the big stuff. Demonstrate as much value as you can. Solve the problems you know how to but don't solve them throughout the whole system just yet. You can do that later. Yes, you'll develop a backlog of little stuff that has to be fixed; the time will later come when that is urgent.

Computer Programming is a Slow (, Fun?) Learning process for me

Yes, for me it's a very, very slow, tedious, painstaking one requiring much patience but the rewards seem to be many: it's very, very fun to learn so much and build a war-chest of solved problems that you can apply to the next situation. It's never-ending.

You learned it generally now, take the chance of applying it later

Any time you're unsure if adopting a new practice will help or hinder, don't adopt it. Go down the road on this project with the skills you have today and apply what you learned to the next project or iteration. Learning along the way is most of the fun but we don't have to apply everything we learned / are learning to our current project. We can do that later, in a future project! If you add the things you're learning to this project, you'll never finish; the project will grow and grow.

Today I'm working on a software app for my buddy Andrew. I'm having fun but the going's slow at times and I don't know everything. It is a forms application and the technology I've chosen to use is ASP.NET MVC (http://www.asp.net/(S(d35rmemuuono1wvm1gsp2n45))/mvc/) which I think is basically amazing, but I'm still learning it. In trying to solve the problem at hand, I read some VERY neat-sounding techniques from Brad Adams (http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-4-custom-object-templates.html) on automating form creation in ASP.NET MVC but I don't want to increase the scope of my project; I've got to finish knowing what I know now. I don't want to go down this rat-hole.

Brad's techniques look awesome and like they could save me a bunch of time later, when I have it. But I'm not going to invest in learning it now. I'll plod forward using the skills I have. I'm not a hacker, I am a software developer trying to produce working software as fast as possible. I'm not going to indulge in research activities right now.

Doing anything by yourself is very hard and there's always a better way to do something. There's always something to learn. The lessons we learn on our current iteration or project can be applied to our next iteration, later, when we have a chance to plan.

What’s a good project / program manager? A stable leader.

Someone who can stay afloat. Someone who is confident in their abilities and methods. Someone who is curious and perceives the world as dynamic and pliable. Someone who likes and trusts people. Someone who things that they and their peers are talented and having fun. Someone who can have tons of stuff thrown at them yet know the way forward and what to do next. Someone who is a planner. Someone with a plan. Someone who can backlog, prioritize and not burn out themselves or their teams. Someone who stresses out infrequently and contains it very well when they are stressed out. Someone who is cool under pressure. Someone with systems, standards and strategies. Somoene you want to work with who will not throw you under the bus or add unnecessary stress to your life.

Sometimes you may want waterfall development; but the luxury will cost you!

Sometimes you simply don't care about the specifics of what comes out the other end of the engineering process. Either because you have high expectations and high trust in what they'll deliver. "High engagement" with the engineering department will cost you time and energy. "Low engagement with engineering will cost you in time and rework, waste, and cost

There are times, like when a business person builds a prototype of a system or clearly defines the product requirements, that they can give that input to engineering to harden and tighten the design. In such a case, the inventor(s) of the prototype or specs may not really care what comes out the other end; their requirements are fundamentally qualitative: 1) Make it look good 2) Make it performant 3) Make it "tight". Managing a project in such a way is possible and sometimes desirable. But there are alternatives.

Not everyone wants to engage with an engineering group in an Agile / High Bandwidth way. They need room and space. They don't want to be an engineer. Weekly check-ins (like in Agile) seem reasonable but maybe some people would prefer monthly, quarterly, or annually. The larger the period between reviews and meetings, the larger the budget, the more the risk, the bigger the problems, the lower the quality.

Technology Things I’ve Learned Recently

Installing and using Eclipse. Installing WordPress and Drupal. Installing Drupal modules. Customizing Drupal. Things about ASP.NET MVC version 2.0. DataAnnotation in .NET. SSIS packages and catching error rows. Silverlight application development techniques. About RIA Services. There's a lot of great stuff out there.

Good Governance is Sitting Down with the Governed

You can write all the rules you want in an attempt to make people comply but the best way to get result and learn from others experiences is to sit down with them. Take the time to do this today!

Modified Version of Alvin Toeffler Saying

Coding is the easy part. The hard part is to discover and apply technologies that can continuously fit the business needs and problems.

The Users Need It Now!

Don't procrastinate. Get the software in their hands ASAP. The business process is the thing that matters and unless the tool or software is in-hand, you won't know what it is and what needs to change. Deliver now.

Hacking vs. Solving Root Cause – Level 1 and Level 2 Problem Solving

Stopping the bleeding and fixing what's in front of you is way different from solving the ACTUAL problem (not surface problem). I'll write more about this soon!

Capabilities Increase Scope

So ultimately it seems that having multiple developers changes the REQUIREMENTS of the solution and for that reason, the velocity. Assuming that all developers are stuck with where they are at with their own personal velocity until they read something great or get help from a peer. So if developer A knows how to do thing M and N and developer B can do thing O, then the total requirements for the solution are likely M, N, and O. For me, I'm operating on M and N now and the solution is "simple". If I could find someone who could do thing O, then it would take longer. Pragmatism is odd.

Individual vs. Team Work Velocity

It'd be very nice to always have a team (or at least a pair) of developers, but sometimes this isn't possible; sometimes we've got to 'go it alone'. I'm doing that right now on an app for my friend. I'm fairly good with the basics of getting things to print on the screen but when it comes to making things elegant and beautiful, I am way weaker. I consider these weaknesses "low pri" but if I had another person looking over my shoulder they may be able to help me. Right now I'm going to punt these things I can't do elegantly and am backlogging them with "TO DO:" statements in my code. This isn't a major concern but it raises the question for me of the difference between an individual and team's velocity. In an idea world, all developers would be able to work by THEMSELVES as fast as they possibly can. But there is overlap often, and people have to help people, and there is a team, so what would the net-net of adding people to a team be? Definitely more communication channels…

Find Ways to Tell Your Story to the People You Want, the Way You Want

If you're ever feeling frustrated, stuck, depressed, etc. don't get too down. Sometimes we feel like we're in a rut or mire that we can't escape and want to isolate ourselves from others, make decisions to protect ourselves and avoid interaction with people so we don't have to tell them a sad story or show them how bad or disappointed we feel on the inside.

As far as I can tell, people and activities are our best means for getting out of ruts. Find your believers and keep engaging them. Seek new believers, really anyone who will listen or share themselves. Keep talking, keep laughing, keep meeting people. Eventually you'll get to tell your story to the person or people you want in the way you want and you will feel very happy!

Punt the shit you can’t do well now

If you don't know how to do something now, don't do it. Do the bare minimum and put in a placeholder or wedge so you can move onto the next more important thing. If you are truly good at the rest of what you do (your trade) and getting the job (as you can do it, on time), you will attract supporters, followers, and believers. These people will be able to help you later and provide you with the time and support you need to complete the product or project on time, on quality and to your mutual enjoyment. Done is when everyone's happy, not when you're tired.

Incrementalism

Word of the day for me. It matters. Maybe more important than pragmatism? Do things in bites; bite-sized chunks. Remember your goal but focus on the near-term and task ahead. I'd rather do things small and incrementally (take baby steps and solve problems that are "bite-sized") than feel like I was eating an elephant. As long as we have enough time to break and breathe between bites of the elephant of life and our ambitions, we'll be fine. The elephant in fact is really the aggregation of all of the bites we are able to take of it. The elephant is fictitious to us and of a potentially infinite size. But don't make it so. Figure out how you can eat the elephant faster and more tastefully and who knows how many elephants you'll be able to eat!?

Sure, it's also great to have a vision and ambition and an appetite for eating lots of elephants and boiling many oceans, but you need to be able to (regardless of how large your challenge is…thank god you're not President of a nation or something ridiculous like that) do the next thing, take the next step, figure out what you CAN do next, successfully.

“Instrumented Reality”

We seem to want things to throw off data. We want to measure and see our world visually. Not just as they appear but with augmented reality; data overlays. We want to want to measure (in a computer system) what is going on around us.

Instrumented systems (see New Camera System that Takes the Guesswork Out of Baseball Stats http://www.popsci.com/technology/article/2010-01/taking-guesswork-out-baseball-stats) are our new databases. Many systems are now database information systems. They are organic and constantly changing yet digitized and software-enabled. We can present their data and rethink them however we want.

The world is apparently not good enough. What's up with that!?

What’s an Architect?

The first person on the scene. The solver. The guy who can do it. The guy who can create the solution. The doctor, the lawyer, the dentist. The main man. The most knowledgeable person about a topic. Similar to an analyst but this guy knows how to actually create the thing. An analyst might know how to do this but this is the guy that can actually do it and does it. He probably directs other developers to do stuff. He has the keys to the kingdom and can ride the fence between business needs and requirements and pragmatism / practicality in solution and design.

Chartering Should Primarily Come from the Customer

As I said before, hack around…things don't have to be perfect. Once you have a user, a stakeholder, a second on-looker to your work, integrate their suggestions and turn their needs and requirements into the best product possible. You should be hacking less and working on important stuff more when there are customers and users.

Putter ‘til you find a Project

Putter around, fix stuff, it doesn't have to be pretty or perfect or solve "root cause". Just fix things up, be busy, get tidy and eventually you'll stumble upon an important project that's worth tackling.

Demonstrate a Wealth of Options but Have One in Mind

It's great to show coworkers and customers everything that is possible but if you don't have a clue which one to use, which one is best, what your preference is, etc., you're clueless. Get a clue.

What’s an Analyst?

Someone who can think. Someone who can analyze. They can look at data clearly and solve problems. They don't easily get frustrated. They seek solutions. They can clearly and concisely identify blocking issues and impediments to progress. They know what the current largest problems are. They have a forward direction in mind; they have goals. They are someone who knows that there are usually several next steps that could be taken and are capable of advising you on what the next steps are. They may get distracted easily while swimming in a sea of information. Once a decision is made or action is taken, they create a new world view and context from which they continue to analyze. They seek knowledge above information. They are likely good teachers. They are definitely learners and probably doers. They can observe what is going on and determine opportunities for improvement.

Authorization is Odd

Who is authorized? Who can do this? Who is in charge here? There's a lot of confusion in the world. Sometimes we don't feel authorized to do what we need to do. We perceive many rules and go along with what we think to be the status quo. But is that really the status quo? Maybe the status quo is change, chaos, and disorder. There are rules and there are ways around the rules. Be bold and more forward!

How to feel consistent while searching for work

If you're on a short contract, stay until the end.  In the meanwhile, plan for the end and move onto the next thing but keep doing well at what you're currently doing.  Maybe it'll get better!  Don't be a slacker.  If you're on a longer contract or in a permanent job, it's harder to leave and give notice.  Be strong, give two weeks and move on.  Don't look back.  Be thankful for what you have, your relationships, and the people you've worked with.

The Application Layer is All That Matters

I think that this layer is the only layer that matters.  It is the business process, it is the interaction between the user and the computer.  It is workflow and the movement of data.  It is all about the purpose for which the computer exists in the first place.  It is instrumented, it is intelligent.

How Does Business and Economic Development Work?

It's all about trust in my opinion. You should do your own, it'd be nice if you could have someone to do it for you, but that has a potential cost. How do you think we need to grow the economic pie?

Where does work velocity come from?

Accountability of individuals and between team members.

The Tools of Programming

You need some pretty basic stuff: a data store (place to keep the data also called "model", not to be confused with the overall system model / concept), a transformation / business logic layer (this is the thing that takes user input and converts it to and from the data store (these are also your "controller"), and a UI / front-end. The UI need not be graphical, it could be a phone, text message, whatever, you just have to be aware of the interactions with the system that you create and handle the user input and output of different views / screens to the user. This is also called the "View". Happy programming!

No Really, Show Value as Fast as You Can, Dammit!

I've probably said this before and I'll say it again, but the goal—I think ALWAYS—is to show value as fast as you can. This means that you could have had an agreement and understanding with someone before but it was most likely based on unlimited information and a "gentleman's agreement". Once you get down to doing the work and delivering, the real goal is to indeed (as I'm saying here) SHOW. VALUE. AS FAST. AS YOU CAN (and repeatedly for that matter). This is huge!!

I'm working on a pro-bono project for a friend of mine now and even on this, I'm following this principle. I just got his data loaded into the database and the next thing I am going to do is to spit out a bunch of sample data to the screen to show him that I'm making headway. I want to make sure he's engaged, involved, committed, and excited for what I'm building and the best way to do so is through DEMONSTRATION. This principle applies in most (all?) fields.

Crazy Making

So much for my great ideas about bridging the gap from back end to front-end. I'm now way back in the back end, creating some extremely old school hack because the middle tier wasn't working right. BOOOOOOOOOOOOOOOOOOOOO! Here's how to have an OUTPUT from a Stored Procedure that uses Dynamic SQL.

CREATE
PROCEDURE Myproc

@parm varchar(10),

@parm1OUT varchar(30) OUTPUT,

@parm2OUT varchar(30) OUTPUT

AS

SELECT @parm1OUT='parm 1' + @parm

SELECT @parm2OUT='parm 2' + @parm

GO

 

DECLARE @SQLString NVARCHAR(500)

DECLARE @ParmDefinition NVARCHAR(500)

DECLARE @parmIN VARCHAR(10)

DECLARE @parmRET1 VARCHAR(30)

DECLARE @parmRET2 VARCHAR(30)

 

SET @parmIN=' returned'

SET @SQLString=N'EXEC Myproc @parm,

@parm1OUT OUTPUT, @parm2OUT OUTPUT'

SET @ParmDefinition=N'@parm varchar(10),

@parm1OUT varchar(30) OUTPUT,

@parm2OUT varchar(30) OUTPUT'

 

EXECUTE
sp_executesql

@SQLString,

@ParmDefinition,

@parm=@parmIN,

@parm1OUT=@parmRET1 OUTPUT,@parm2OUT=@parmRET2 OUTPUT

 

SELECT @parmRET1 AS "parameter 1", @parmRET2 AS "parameter 2"

go

drop
procedure Myproc

Close the Gap Between the Database and UI

This is no small feat to overcome and to do it means that you can build an entire software application by yourself; all tiers! Not relying on the DBA, Designer, and Coder roles, but on you as the focus in the role(s) of Architect/Manager/Producer. I wrote years ago about "top heavy" applications that repeat logic in the model, views, and controllers. I'm hoping that today we're closer to having the Model Driven Architecture gap bridged: the holy land of software!

Going with the Flow and Being Flexible

Say you create something really great and people like it. You show it to them and they want more. They want to help you build it and work on it. You may have started as "that guy" who was doing some random thing, but depending on how you play your cards, you could become "THE guy" who is at the center of it all. Follow your products and creations around; see where they take you!

In Software, You Can Harden and Tighten Your Design Later

I said it earlier, but don't be a perfectionist in what you create. Don't make the first product you produce perfectly right and tight the first time. Leave some room for enhancement and improvement. Get a working product in their hands as fast as you can and fix what's broken later.

<Rant> The “Cloud” in Cloud Computing is a Stupid Name

Come up with something new, people! It's like saying "fog". People are foggy and cloudy on the cloud. They don't know what it is. I don't know what it is (in total) and I think I should. That's a problem if you're trying to sell someone something more than snake oil. Let's start offering real value and get clear on what the cloud—or our service in the cloud—is!!!

Refactor Later If Necessary

Don't be a perfectionist about the software you're designing. There's always another time you can come back and fix what you built. That's the beauty in fact about object-oriented or component-oriented programming is that the components are "swappable". If I messed something up this time around, I can always go back and fix it later. Insist, however, that the STRUCTURE you create is very good and that you have a solid, defensible, base architecture to stand on. Be fine with rafactoring later if you have to; you'll probably have to.

Be Cool Under Pressure

Sometimes you have to deliver rapidly and set expectations with people. You could burn yourself out and work 80 hour weeks or you could take it easy. Be cool, confident, calm and don't burn yourself out. Make reasonable commitments with people if at all possible.

Get Refocused

I feel distracted at the moment. My main project at work is out of mothballs and I'm trying to get things done on it. The learning curve on Silverlight, RIA Services, and passing data from SQL Server isn't easy. I must plod forward.

The Librarian Role is Needed

In companies there needs to be a librarian or secretary. Teams are busy and produce a lot of things. Even with good IT systems, things don't get checked in and project results or artifacts stay on local machines. This is a knowledge management problem when the resource moves onto something else and frequently causes rework. I propose the role of LIBRARIAN. This person would make sure that everything is done. This is a hat the project manager or functional manager could manage.

Lots to Learn in Programming User Interfaces

It takes a long time to get good at programming. I still don't feel like my "toolbox" is working very well from the front-end to the back-end. I am stronger on the database side and now I have to bridge the gap up to the UI. The UI technologies are crazy in my opinion. Silverlight and .NET RIA Services are compelling. I like how they're working with data binding. .NET 2010 seems to have some cool data binding "drag and drop" functionality (see http://channel9.msdn.com/posts/kmcgrath/Silverlight-Object-Binding-in-Visual-Studio-2010-Beta-2/). ASP.NET MVC is different. I'm more familiar with HTML as my UI and JQuery is a very nice extension for that… Windows Workflow Foundation (WF) is another that I'd like to use here to figure out how to handle the different activities in the workflow I'm currently designing. Another cool / promising technology is .NET Entity Framework. Looks cool and now there's going to be SQL Server Modeling Services and a language called "M". So much to learn!!

Defer in Order to Manage Multiple Customers and Interruptions

I've had the luxury for about three months now of working on projects that have been generally serial in nature. That's changing a bit as I've finished a few things and they're in peoples' hands.

I'm going to implement a new personal policy that is to start and finish the highest priority thing as soon as I can "reasonably wrap up and mothball" what I'm currently doing. I'm currently working on an app that is due in a few weeks. I'm going to finish any loose ends, write down my next steps and move onto the other more pressing thing now. I'll dredge up the other project when I'm done with the current one.

Ideal Software Development Manager

Listens well, writes code, willing to help, willing to be interrupted, not too busy or randomized by other things, values you, smart.

Plan for a Longer Review When the Next Task is Big or Important

I have a problem that I'd like to share with a coworker to get his input. He's really the customer on this so I don't want to waste his time. I have to get ready to ask the question and engage him. This particular question I want to be reasonably BIG because I want to spend some time with him designing the next mini-sprint or story I'm working on; really the finish of this iteration of the product: the first prototype! I've basically finished my current story "build middle tier" and now I have to work on the next story "enable front end". The new story is pretty complex for me and I don't know much. He doesn't either. I could start in on it and ask him things as I go, bit by bit, but I may ask now, show him what I have so far and step into the next big problem, chartered and re-energized by him.

I'm an idealist and want to have shared mental models and designs between people. I don't want to work alone but sometimes I do and have to. This is the case now where I want to take the risk of engaging the customer so we can co-visualize and plan the last leg of his/her project. I don't want to annoy this person but I want to keep them engaged and involved.

Back-to-Front vs. Front-to-Back Systems Design

We all think in models and our computers allow us to build models, so of course use them, right? It would be ideal to have a model of our system that we instantiate. We draw something or configure something and a system comes into existence. That's the basic practice of development but it's much different and far more iterative going from front to back and back to front. Writing code is a sometimes aggravating process as you validate your coding concepts against your mental model of the ideal (or good enough) solution. The Model-View-Controller pattern is very popular these days with Ruby on Rails and ASP.NET MVC. These solutions allow developers to pass data between the layers and control how things are presented. There's a flow they have in mind and that's a really handy tool! I'm building a Silverlight UI right now and I'm preparing the underlying data model for on-screen display. SOMEHOW I have to sync up the back end with the controls and intended user scenarios in the front end. That's tricky. I've been working from back to front but now I'm having to go from front to back. Somehow these worlds will collide!

Computers will be better when:

When software engineers figure out how to allow a user to drag objects around and relate them to other objects in many flexible ways (not just hierarchies), computers will be way more powerful.

Enjoying the Tranquility of Authorized Research

I was obsessing yesterday over the idea that I didn't know how to do "data binding" in .NET. I wanted get help from my coworker because I thought he knew about it but it turns out he doesn't. I talked to him this morning and he told me to do the reading and research necessary to "get 'er done". Cool! So now I get to become my team's resident expert on data binding in Silverlight on .NET. I'm looking forward to experiencing the tranquility of learning something new and want to learn, at my pace, on a cool project, at least for the moment. Thanks, V!

Refactor Later

Start and finish your design. You may not know exactly how to do it but you need to finish. Surely you can engineer a way to make it work but don't get bogged down in asking too many people for input. Maybe don't ask anyone for input at all. You can get the input later when you finish and at that time, either enhance this creation or the next one.

Some preferences don’t matter; they are for you

Sometimes you may think you want people to offer input on something you're designing but you typically don't need this. Keep steaming ahead and make decisions about the design as you see fit. Be creative.

It’s better to ask for forgiveness than permission

Authorize yourself to do something really good today. Maybe the others won't like it, but finish it and make it tight. Show it to them and gauge their reaction. Without a doubt it will be a learning experience.

Don’t be parochial, get the job done!

I've blogged before about how you have to wear different "hats" to do well in IT. I think the hats are: project manager, program manager, product owner, customer, developer, and tester. That said, as a consultant (or employee for that matter!) the "that's not my role" mentality is completely retarded. Don't do it. Wear many hats and don't develop a not invented here mentality! Make sure you develop skills in all of these disciplines and figure out how you can get the job done if you're given any of these tasks. Learn from the masters of these roles and be the "project manager" to drive toward getting the job done. Don't be parochial!

Training Product Owners Is Challenging

Customers can be difficult of course. I say this because many people might not know what they want or how to get there and your job as a software development consultant or team leader is to communicate with this person as effectively as you can and give them products that they can use in THEIR processes. Some core skills and lessons that you need to teach the product owner (whoever he or she may be are): 1) software development is difficult 2) there is uncertainty in how the solution will be exactly created and knowing what exactly will come out is a minute-by-minute problem for a software developer or leader 3) estimating when you'll be done is difficult 4) there exists a process of continuous improvement and improvement of the customer relationship. That process referenced in #4 is YOU!!!

Waterfall doesn't work a lot of but it's fine to have frameworks and principles that you follow. CMMi, Six Sigma, Agile, PMBOK, MVC, etc. They all matter. In the end, something has to get done and agile is a way of breaking up the problem FROM THE BEGINNING about what needs to be done next. What's the risk? What's the priority? Can we do it? When do you need it? Removing as many of these impediments as is possible as fast as you can is the way!

I Learned a Lot About Software Development and Communications from Scott B.

A former coworker, Scott Brown, knew Agile. He'd lived it on the CodePlex program at Microsoft. I wasn't a current practicing developer at the time I was ScrumMaster of that group but I am now. I probably learned the most from Scott. He was very pro-Agile; a zealout, I'd say, but retrospectively he knew a lot about the process and effective communications. He was all about velocity and getting things done; pragmatism. Our team wasn't probably ready at the time for that level of engagement (I know I wasn't) but I am now.

Thanks to Scott for showing me how software development can be fun and we can reduce randomization through quality communications.

Get to a working demo as fast as you can!

You can potentially be perfectionistic and want what's perfect for your app but in the end you have to release it to users and let them break it. Think through the risks and issues of the scenarios they're going to do and plan for that. What are the scenarios? How will you know that they're working well? Answering those questions should be the input to your sprint and its "definition of done".

Cautiously Demo Your Work to Build Relationships with Customers

Caution is the key word here. You don't want to bore people. Let me explain:

The purpose of the demo (or asking for help, input, etc. from your customer or manager, teammate, etc.) is to impress upon them, and to build your relationship with them as much as you can. The more they like you, the better off you are; the more they'll like your products most likely. The more you waste their time with triviality or demos that suck, questions that are obvious or that you could have answered on your own, the more you'll turn them off, bore them, and generally make them dislike you. Sure, they may care about you as a person but what they really care about AT WORK is the product and its QUALITY. If you demo boring stuff or unfinished things or things that simply confuse them, they'll disengage and possibly dislike you, probably ignore you. They'll avoid your products as well. You don't want that.

In total, THINK HARD before you ask someone for help or look at your work. Be in control of what's being presented and don't welcome scrutiny or doubt in your approach. If the demos are good and you get the kind of feedback you really needed in the first place then you'll be in the good! Avoid "ringing the bell" at any given moment; bang the gong when you're ready to summon them!